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ABSTRACT 
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other  AUVs  was  implemented  and  demonstrated  in  the  Naval  Postgraduate  School 
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bandwidth  underwater  data  transfer  methods  in  order  to  enable  accelerated  access  to  data 
collected  by  a  network  of  data-gathering  survey  AUVs.  Rendezvous  was  implemented  by 
autonomous  reconfiguration  of  ARIES’  operations,  using  a  mission  planning  module  to 
combine  acoustically-transmitted  rendezvous  requests  from  survey  AUVs  with  pre-stored 
survey  AUV  mission  data  to  generate  rendezvous  missions  based  either  on  time-optimal 
or  energy-optimal  trajectories.  The  planning  module  efficiently  generates  rendezvous 
trajectories  based  on  solutions  derived  using  optimal  control  theory.  A  new  third  layer  of 
control,  based  on  a  finite  state  machine,  was  added  above  ARIES’  autopilot  and  mission 
execution  functions  in  order  to  initiate  mission  planning  and  replanning,  activate 
missions,  sequence  vehicle  operations  through  seven  defined  states,  control  acoustic 
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I.  INTRODUCTION 


A.  MOTIVATION 

This  work  furthers  the  capabilities  of  an  evolving  class  of  robot,  the  autonomous 
underwater  vehicle  (AUV).  AUV’s  represent  the  latest  development  in  a  centuries-old 
progression  of  human  efforts  to  work  in  the  marine  environment,  efforts  motivated  by 
economic,  scientific,  military,  and  other  reasons. 

Work  in  the  marine  environment  is  difficult  on  many  levels.  Human  operators  are 
out  of  their  natural  element  and  require  protection  and  life  support.  Communications 
bandwidth  and  range  are  more  limited  than  for  most  other  environments.  This 
complicates  the  control  of  underwater  systems,  and  can  result  in  loss  of  the  system  due  to 
an  inability  to  communicate  with  or  locate  it.  Significant  forces  such  as  winds,  waves, 
currents,  and  hydrodynamic  and  hydrostatic  forces  affect  and  disrupt  operations.  The 
environment  is  corrosive,  fouling,  and  incompatible  with  electrical/electronic  equipment. 
As  a  result,  operations  tend  to  be  difficult,  time  consuming,  expensive,  and  hazardous  to 
both  machine  and  operator. 

AUVs  are  a  recent  solution  for  achieving  desired  objectives  in  the  marine 
environment  while  addressing  and  overcoming  the  inherent  challenges.  As  technology  in 
any  field  of  work  advances,  it  is  leveraged  to  maximize  benefit  and  minimize  cost.  The 
same  is  true  in  this  context.  Beginning  with  boats  and  nets,  human  ingenuity  has 
extended  man’s  presence  and  capabilities  in  the  marine  environment  to  maximize 
benefits  while  reducing  the  costs  and  risks  of  doing  so.  Advances  in  technology  brought 
successive  improvements  in  marine  propulsion;  progressing  from  oars,  to  sails,  to  steam, 
to  nuclear  and  other  current  methods  of  propelling  vehicles  delivering  cargo,  warheads, 
sensors,  or  other  payloads.  Sensors  evolved  from  the  lead  line,  used  for  taking 
soundings,  to  sonar  for  taking  soundings  and  locating  objects  other  than  the  sea  floor,  to 
high  resolution  sonar  for  identifying  the  details  of  the  sea  floor  and  underwater  objects. 
Cameras,  line  scanners,  magnetometers,  sub-bottom  profilers,  and  numerous  types  of 
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oceanographic  sensors  have  been  developed  to  further  man’s  reach  into  and 
understanding  of  the  marine  environment. 

A  key  element  of  man’s  operations  in  the  marine  environment  has  been  the 
human  element  itself,  which  has  been  a  bit  of  the  proverbial  “double  edged  sword”.  On 
the  negative  side  are  such  liabilities  as  the  costs  of  salaries,  benefits,  and  training;  the 
costs  and  logistics  of  protection  from  the  elements  and  of  life  support;  time  lost  to  rest 
and  recreation;  and  the  consequences  of  injury  or  loss  of  life.  As  is  the  case  in  such 
endeavors  as  space  exploration,  protecting  and  supporting  human  life  entails  significant 
increases  in  the  size,  complexity,  and  expense  of  equipment;  reduction  of  mission 
duration;  and  added  risk.  The  positive  side  of  the  human  element  is  its  unmatched 
versatility  for  perfonning  a  variety  of  tasks,  for  which  there  has  long  been  no  substitute  in 
the  complex  marine  environment.  Additionally,  unexpected  situations  frequently  occur 
requiring  human  intervention,  as  human  intelligence  and  reasoning  are  unequalled  for 
making  the  appropriate  decision  in  dealing  with  the  new  situation.  Although  removing 
humans  from  such  operations  is  highly  desirable  from  a  liability  standpoint,  doing  so  has 
been  challenging.  Automation  has  advanced  the  process  of  removing  the  human  element 
over  time,  starting  with  the  simplest  tasks.  Many  more  complex  tasks  are  yet  to  be 
successfully  automated.  The  human  element  enhances  operations  in  the  marine 
environment,  albeit  at  a  price.  A  desirable  goal  would  be  to  remove  the  human  element 
while  preserving  the  effectiveness  inherent  in  it. 

AUVs  remove  the  human  element  almost  completely;  more  so  than  in  related 
unmanned  aerial,  land,  space,  and  sea  surface  vehicles.  Communications  methods 
available  to  these  other  vehicles  provide  ample  opportunity  for  human  participation  and 
intervention  during  the  course  of  a  mission.  AUVs  are  significantly  constrained  in  their 
ability  to  communicate  with  external  operators,  and  are  therefore  highly  dependent  on 
autonomous  operation.  The  nature  of  their  operating  environment  motivates  much 
progress  in  the  field  of  autonomy. 

B.  HISTORY 

Development  of  AUVs  has  progressed  in  stages  over  the  last  few  centuries.  As  is 
frequently  the  case,  military  operations  provided  significant  motivation  to  develop  and 
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advance  technology.  As  in  the  above  discussion,  military  effectiveness  also  benefits  from 
inclusion  of  the  human  element.  And,  as  above,  the  desire  to  minimize  the  cost  and  risk 
of  human  involvement  motivates  developments  in  automation.  One  typical  military 
objective  throughout  history  has  been  to  deliver  an  effective  explosive  charge  to  the 
desired  target  with  the  objective  of  destroying  it.  Over  time,  automation  has  gradually 
replaced  human  methods  of  delivering  the  charge  to  the  desired  target.  In  1585,  during 
the  siege  of  Antwerp  by  the  Spanish  Annada,  defenders  of  the  city  sent  an  unmanned 
vessel  filled  with  explosives  and  fused  with  a  timer  down  the  river  Scheldt.  It  succeeded 
in  its  mission,  which  was  to  blast  an  opening  into  a  barricade  built  across  the  river.  The 
automation  required  was  minimal,  as  the  river’s  hanks  constrained  the  vessel’s  path  to 
arrive  at  the  barricade,  its  flow  brought  it  to  the  barricade,  and  the  timer  needed  only 
delay  the  explosion  until  after  the  vessel  was  swept  against  the  barricade  (Gray,  1991). 

The  more  challenging  and  useful  situation  involved  delivering  the  explosive 
payload  below  the  waterline  of  a  moving  target  in  open  water.  The  spar  torpedo,  placed 
on  the  end  of  a  long  pole  at  the  bow  of  a  small  manned  vehicle,  represented  an  early 
solution.  This  involved  a  human  element,  which  guided  the  vessel  and  its  attached 
explosive  payload  to  the  intended  target.  The  human  cost  and  risk  was  to  be  mitigated  by 
the  distance  provided  by  the  length  of  the  spar,  or  by  the  length  of  a  rope  that  was  pulled 
taut  to  detonate  the  torpedo  after  it  was  implanted  in  the  target  and  the  delivery  vehicle 
backed  away.  As  was  demonstrated  by  the  CSS  Hunley’s  sinking  of  the  USS  Housatonic 
during  the  Civil  War,  the  weapon  with  it’s  human  controls  was  very  effective;  but  the 
loss  of  the  Hunley  also  demonstrated  that  the  cost  was  too  high  and  that  further 
automation  of  the  concept  was  necessary  (Bak,  1999).  The  desire  to  achieve  the  same 
level  of  effectiveness,  but  at  lower  cost,  resulted  in  development  of  possibly  the  first 
AUV,  the  Whitehead  torpedo.  It  was  developed  by  Robert  Whitehead  during  the  latter 
part  of  the  19th  century  and  further  removed  the  human  element.  In  fact,  once  launched, 
there  was  no  human  element.  Whitehead  overcame  significant  technical  challenges  in 
designing  a  suitable  propulsion  and  control  system  for  his  torpedo.  Propulsion  was 
provided  by  a  variety  of  different  engines,  and  control  was  provided  by  a  combination  of 
gyroscope-based  heading  control  and  depth-cell  based  depth  control  (Gray,  1991). 
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Current  torpedoes  and  AUVs  are  improvements  on  Whitehead’s  invention.  His 
propulsion  designs  were  succeeded  by  internal  combustion  engines  or  electric  drive 
powered  by  various  types  of  batteries.  His  straight-running  torpedo  carried  no  sensors, 
other  than  an  exploder  to  detonate  the  warhead  when  it  sensed  contact  with  a  solid  object. 
However  follow-on  torpedoes  carried  equipment  such  as  wake  or  acoustic  sensors  to 
detect,  track,  and  home  on  targets;  as  well  as  magnetic  and  other  sensors  to  sense  the 
proximity  of  a  target  and  detonate  the  warhead  at  the  appropriate  time.  Additionally, 
enabling  a  torpedo  to  process  its  sensor  data  to  home  in  on  a  target  required  the  addition 
of  computational  capability,  first  analog,  then  digital  (Naval  Undersea  Warfare  Center, 
1998).  Military  necessity  brought  a  high  level  of  autonomy  and  technical  sophistication 
to  underwater  vehicles. 

Torpedoes  represent  one  path  of  development  towards  AUVs,  another  was 
progress  in  sensor  technology.  Beginning  with  lead  line  soundings  taken  by  dropping  a 
tethered  weight  to  the  bottom  to  detennine  water  depth,  a  variety  of  tethered 
measurement  devices  and  sensors  have  been  used  in  the  ocean  environment.  These 
include  oceanographic  instruments  and  camera  sleds.  The  device  was  lowered  to  the 
desired  depth  at  the  desired  location  to  take  the  measurement  or  image,  then  brought  back 
to  the  deploying  vessel  where  the  data  was  downloaded  from  the  device  (McConnell, 
1982).  This  method  of  gathering  data  did  not  allow  access  to  the  data  until  the  device 
was  removed  from  the  area  to  be  sensed  and  back  on  deck.  This  not  only  delayed 
presentation  of  the  data  to  the  human  operator,  it  prevented  adaptive  planning  of  the  data 
gathering  operation  based  on  conditions  sensed  by  the  device  (Andrews,  2004). 
Improvement  came  with  tethers  which  also  contained  communication  channels,  such  as 
wiring  or  optical  fiber.  Access  to  sensed  data  was  available  instantaneously,  and  the 
device  could  be  repositioned  in  response  to  the  sensed  data  to  adaptively  plan  the  data 
gathering  operation  and  improve  the  usefulness  of  gathered  data.  The  feedback  provided 
by  the  communications  link  made  control  of  the  tethered  device  possible,  and  gave  rise  in 
the  1950’s  to  remotely  operated  vehicles  (ROV)  (Marine  Technology  Society,  2003).  An 
ROV  is  typically  outfitted  with  thrusters,  control  surfaces,  and  other  equipment  such  that 
a  human  operator  can  drive  the  ROV  by  remote  control  in  the  performance  of  its  mission. 
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This  link  to  a  human  element  allows  ROVs  to  perform  complex  undersea  missions 
without  the  actual  presence  of  the  human,  eliminating  the  need  for  human  requirements 
such  as  life  support  and  protection  at  depth.  Instead,  the  human  element  is  located  at  a 
safe  distance,  either  on  a  support  vessel  or  at  a  networked  location  thousands  of  miles 
away.  Additionally,  the  electrical  connection  to  the  surface  vessel  provides  essentially 
unlimited  power  to  the  device 

Versatile  as  ROVs  are,  there  are  still  limitations  to  be  overcome.  The  requirement 
for  a  tether  and  support  vessel  limits  the  operations  of  the  ROV  to  the  length  of  the  tether, 
and  the  speed  at  which  the  tether  can  be  towed.  Additionally,  the  necessity  of  the  surface 
vessel  limits  ROV  operations  to  areas  accessible  to  the  surface  vessel,  something  which 
may  be  constrained  by  sea  conditions,  hydrography,  ice,  hostile  action,  or  the  desire  to 
remain  covert.  Also,  there  is  the  expense  of  a  continuously  present  support  vessel. 

AUVs  represent  a  follow-on  development  in  both  sequences  of  technological 
progress.  They  build  on  the  fusion  of  propulsion,  control,  and  guidance/logic  technology 
developed  to  improve  torpedo  capabilities,  and  they  are  used  as  platforms  to  carry  the 
sensors  that  have  been  tethered  to  other  vessels.  In  doing  so,  those  sensors  may  be 
employed  more  effectively  than  by  tethered  or  other  means. 

C.  AUV  APPLICATIONS 

Many  applications  for  AUVs  have  been  realized  or  are  under  development.  Naval 
missions  include  deep-ocean  search  (Urich,  1995),  mine  countermeasures  (Wernli,  1997), 
oceanographic  measurement  (Peterson  and  Head,  2002),  intelligence,  surveillance, 
reconnaissance,  anti-submarine  warfare  and  various  support  missions  (Department  of  the 
Navy,  2000). 

An  example  of  an  economic  application  is  the  Hugins  AUV,  which  has  been  used 
extensively  and  effectively  for  offshore  petroleum  exploration.  It  carries  a  variety  of 
sensors  to  the  vicinity  of  the  ocean  floor,  a  task  previously  performed  by  a  sensor  towed 
by  a  surface  vehicle.  By  overcoming  the  speed  and  maneuvering  limitations  associated 
with  the  towed  deployment  scheme,  survey  time  is  reduced  by  over  50%  (Chance,  2001). 
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AUVs  are  used  extensively  to  gather  oceanographic  data,  bringing  methods  of 
measurement  previously  not  possible.  They  have  been  deployed  under  ice  (Jones,  2002), 
where  surface  vessels  could  not  operate,  gathering  data  faster  than  would  have  been 
possible  by  boring  through  the  ice  from  above  and  lowering  instruments  to  take 
measurements.  Long-duration  AUVs  such  as  gliders  have  remained  at  sea  and  gathered 
oceanographic  data  for  extended  periods  of  time  without  the  need  for  a  support  vessel, 
and  have  demonstrated  the  ability  to  operate  from  an  undersea  dock,  periodically  leaving 
to  gather  data  and  returning  to  download  data  and  recharge  batteries  (Curtin  and 
Bellingham,  2001). 

D.  AUV  LIMITATIONS 

AUVs,  however,  are  by  no  means  a  panacea.  For  all  their  advantages,  there  are 
areas  in  which  they  are  inferior  to  tethered  vehicles.  One  consequence  removing  the 
tether  is  that  power  is  limited  to  what  can  be  carried  onboard.  This  limitation  was  the 
motivation  for  the  development  of  nuclear  power  on  manned  submarines,  and  this  same 
limitation  on  smaller,  unmanned  AUVs  that  has  spurred  development  of  advanced  battery 
and  fuel  cell  technology.  Untethered  vehicles  also  allow  little  or  no  human  involvement 
in  their  mission,  due  to  the  limited  communications  bandwidth  available.  As  a  result,  the 
complexity  of  their  missions  is  limited  by  the  degree  to  which  they  can  be  automated. 
Overcoming  this  limitation  motivates  further  research  in  autonomy  and  underwater 
communications.  A  related  consequence  of  this  limited  communications  bandwidth  is 
limited  access  by  the  operator  to  data  gathered  by  the  AUV.  The  most  common  method 
of  retrieving  the  data  gathered  by  the  AUV  is  to  recover  the  vehicle  at  the  end  of  its 
mission  and  download  the  data  via  a  computer  network  connection.  In  time-critical 
operations  the  resulting  time  delay  may  be  unacceptable.  Other  methods,  such  as  low- 
bandwidth  acoustic  communications  or  periodic  radio  communications  periods  on  the 
surface,  are  also  available  but  may  not  be  operationally  desirable.  If  covertness  is  a 
requirement  for  the  operation,  one  reason  for  using  an  AUV  instead  of  a  vehicle  tethered 
to  a  surface  vessel,  such  methods  of  transmitting  data  may  compromise  covertness. 
Methods  of  transferring  data  covertly  and  at  high  bandwidth  exist,  such  as  optical 
(Lacovara,  2003)  or  high  frequency  acoustic  modem  exist  (Kojima,  2002),  but  are  of 
limited  range  (Etter,  1996). 
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E.  SCOPE  OF  THIS  WORK 

This  work  develops  a  high  data  rate  method  of  covertly  gaining  access  to  data 
gathered  by  AUVs.  Such  autonomous,  networked,  accelerated  access  to  data  is  in 
accordance  with  current  Chief  of  Naval  Operations  guidance  (Clark,  2002).  This  work 
implements  the  server  vehicle  concept  proposed  by  (Marco  and  Healey,  2000)  as  a  means 
of  retrieving  data  from  data-gathering  vehicles  to  make  it  available  to  the  operator  while 
the  survey  is  in  progress.  This  method  uses  no  radio  transmissions,  and  limits  other 
transmissions  to  either  short-duration  long-range  acoustic  or  short-range  acoustic  or 
optical  transmissions.  Covertness  is  enhanced  by  this  minimization  of  detectable 
transmissions. 

The  approach  for  accomplishing  this  objective  is  autonomous  AUV  rendezvous, 
in  which  an  AUV  designated  as  a  server  vehicle  is  tasked  to  download  data  from  a 
vehicle  equipped  with  sensors  which  is  gathering  data  on  a  survey,  surveillance,  or 
similar  mission.  After  obtaining  the  data,  the  server  vehicle  delivers  it  to  a  node  where  it 
can  be  transmitted  to  the  operator.  The  operation  comprises  a  network  of  cooperating 
vehicles,  with  a  single  server  vehicle  servicing  one  or  more  sensor  vehicles. 

Such  a  cooperative  vehicle  network  of  cannot  adhere  rigidly  to  a  pre-scripted 
sequence  of  operations,  as  the  unpredictable  nature  of  sensed  data,  navigational  errors, 
disturbances,  and  operational  details  make  a  priori  knowledge  of  all  necessary  mission 
planning  parameters  impossible.  As  a  result,  rendezvous  planning  must  be  adaptive 
enough  to  bring  the  server  vehicle  to  within  short-range  communications  range  of  the 
sensor  vehicle  regardless  of  these  unpredictable  mission  parameters.  Additionally, 
because  the  adaptive  planning  must  occur  during  the  operation  and  after  final  interaction 
with  the  human  element,  the  planning  process  must  be  autonomous.  This  builds  on  work 
by  (Marr,  2003),  wherein  individual  parameters  in  the  AUV’s  mission  were  transmitted 
by  acoustic  command  and  changed  inside  the  vehicle.  In  this  work,  a  set  of  parameters 
describing  the  location  of  the  sensor  vehicle  are  transmitted  to  the  server  vehicle,  which 
uses  the  parameters  to  generate  a  new  mission  for  itself  and  then  executes  the  mission. 

Finally,  the  rendezvous  process  should  be  optimized  in  order  to  satisfy  the 

objectives  of  the  operation.  Because  the  objective  of  the  rendezvous  concept  is  to 
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accelerate  access  to  AUV  data,  it  may  be  desirable  to  plan  each  rendezvous  such  that  it  is 
completed  in  as  short  a  time  as  possible.  Solutions  to  this  time-optimal  problem  will  be 
shown  to  require  closing  the  rendezvous  point  at  high  speed,  a  mode  of  operation  which 
quickly  depletes  the  limited  energy  capacity  of  an  AUV  and  therefore  shortens  its  time  on 
station.  Recognizing  the  energy  limitations  of  AUVs,  it  may  be  desirable  instead  to 
perform  each  rendezvous  using  the  minimum  possible  energy.  These  energy-optimal 
solutions  provide  reasonable  access  times  to  AUV  data  and  maximize  server  vehicle  time 
on  station.  Other  optimization  objectives  may  also  be  desirable.  This  work  addresses  the 
above  two  optimization  objectives,  finding  analytical/numerical  solutions  to  both  and 
implementing  practical  and  efficient  optimization  of  the  rendezvous  solution. 

This  work  made  use  of  the  Naval  Postgraduate  School  Acoustic  Radio  Interactive 
Exploratory  Server  (ARIES)  AUV.  The  unique  behaviors  necessary  for  AUV 
rendezvous;  including  dynamic  mission  planning,  mission  reconfiguration,  command  and 
control  communications,  and  a  new  higher  layer  of  operational  control;  were 
implemented  in  this  AUV. 
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II.  RENDEZVOUS 


A.  SPACE  RENDEZVOUS 

Decades  before  the  space  age  the  orbital  rendezvous  problem  was  being 
considered,  with  a  focus  on  effecting  rendezvous  to  meet  specified  optimization 
objectives.  Hohmann  (1925)  first  solved  the  problem  of  transferring  a  space  vehicle  from 
one  orbit  to  another  while  expending  a  minimum  of  energy.  The  realization  of  space 
operations  in  the  mid  twentieth  century  motivated  extensive  work  in  optimal  space 
rendezvous  (Marec,  1979).  In  fact,  the  vast  majority  of  the  literature  on  the  topic  of 
optimal  rendezvous  pertains  to  space  vehicles. 

Optimization  objectives  of  space  maneuvers  include  the  minimum  energy  and 
minimum  time,  as  will  be  considered  here,  however  the  physics  of  the  space  environment 
are  radically  different.  The  space  environment  is  characterized  by  gravity,  centripetal, 
and  limited-duration  thrust  forces;  whereas  the  AUV  operating  environment  is 
dominated  by  drag,  control  surface,  and  near-continuous  thrust  forces.  As  a  result, 
optimal  rendezvous  solutions  for  spacecraft  have  little  utility  for  AUVs. 

B.  RENDEZVOUS  AND  INTERCEPT 

Of  greater  relevance  is  the  extensive  work  done  with  endo-atmospheric  missiles 
and  underwater  vehicles.  This  is  true  because  these  tend  to  be  finned  vehicles  operating 
under  the  influences  of  thrust  and  drag,  as  are  AUVs.  However,  most  of  the  literature  for 
these  vehicles  involves  intercept  vice  rendezvous.  Figure  1  illustrates  the  difference. 
Designating  the  vehicle  which  maneuvers  as  the  “chaser  vehicle”  and  the  second  vehicle 
as  the  “target  vehicle”,  the  objective  of  intercept  is  for  the  chaser  vehicle  to  match  the 
position  of  the  target  vehicle  at  some  future  point  in  time  along  the  target  vehicle’s  track. 
Intercept  is  a  momentary  condition  satisfactory  for  most  weapons  systems  requirements 
that  are  the  motivation  of  much  of  the  research  on  the  topic.  In  such  cases  a  warhead  is 
detonated  near  the  point  of  intercept  and  no  further  maneuvering  is  necessary.  In  fact, 
warhead  detonation  generally  makes  further  chaser  vehicle  maneuvers  impossible  as  the 
chaser  vehicle  is  destroyed.  Rendezvous  extends  the  concept  of  intercept,  also  matching 
vehicle  positions  but  adding  the  requirement  of  matching  velocity  as  well.  As  a  result, 


9 


there  is  little  if  any  relative  velocity  between  vehicles  and  the  vehicles  remain  in  close 
proximity  for  an  extended  period  of  time. 


a.  Intercept 

Position  Matched 
Momentarily 


b.  Rendezvous 

Position  and  Velocity  Matched 
Sustained 


Figure  1 .  Intercept  (a)  and  Rendezvous  (b) 

C.  COMPARISON  OF  INTERCEPT  GUIDANCE  LAWS 

Intercept  is  a  useful  step  towards  rendezvous  since  an  intercept  trajectory  differs 
from  a  rendezvous  trajectory  primarily  in  the  relatively  short  time  period  just  prior  to  the 
rendezvous.  For  the  remainder  of  the  trajectory,  which  comprises  the  majority  of  the 
trajectory,  intercept  principles  are  of  great  utility.  Many  guidance  laws  have  been 
developed  for  one  vehicle  to  efficiently  intercept  a  target  vehicle,  and  two  that  represent 
the  two  fundamental  approaches  are  known  as  pursuit  and  proportional  navigation. 
These  are  shown  in  Fig.  2. 
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a.  Pursuit 

Target  Relative  Bearing  Nulled 
Chaser  Points  Target 
-  All  Speed  in  Line  of  Sight 


b.  Proportional  Navigation 
Bearing  Rate  Nulled 
Speeds  Across  Line  of  Sight  Matched 
Remaining  Speed  in  Line  of  Sight 


Figure  2.  Pursuit  (a)  and  Proportional  Navigation  (b) 


The  pursuit  guidance  law  acts  to  null  the  target  vehicle’s  bearing  relative  to  the 
centerline  of  the  chaser  vehicle.  By  doing  so  the  chaser  vehicle  always  points  the  target, 
and  all  its  forward  speed  uc  is  applied  in  the  line  of  sight  to  maximize  range  rate  at  any 

given  time.  For  a  stationary  target  in  Euclidean  space  this  law  provides  the  time-optimal 
intercept  trajectory  as  the  chaser  vehicle  is  driven  along  the  shortest  possible  path  to  the 
target.  It  is  a  simple  law  to  implement  since  the  chaser  vehicle  need  only  maneuver  to 
keep  the  target’s  image  in  the  center  of  its  homing  sensor. 

Proportional  navigation  is  probably  the  most  studied  and  utilized  of  the  missile 
guidance  laws  (Zarchan  2002).  It  intercepts  the  target  by  nulling  the  target’s  bearing  rate, 
generating  the  “constant  bearing,  decreasing  range”  condition  that  leads  to  collision 
between  moving  vehicles.  Proportional  navigation  apportions  the  chaser  vehicle’s 
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forward  speed  uc  along  two  orthogonal  axes.  Chaser  vehicle  course  is  adjusted  such  that 
its  speed  across  the  line  of  sight,  uc  ,  matches  target  speed  across  the  line  of  sight  ut  . 

Doing  so  puts  the  target  vehicle  in  a  position  of  having  no  lateral  velocity  relative  to  the 
target  vehicle.  The  remainder  ofwc ,  the  speed  in  the  line  of  sight  uc  ,  is  then  applied  in 

the  direction  of  the  target  in  order  to  close  to  intercept.  For  the  case  of  a  stationary  target 
this  yields  the  same  solution  as  pursuit  guidance. 

Since  its  speed  is  always  directed  at  the  target,  pursuit  might  seem  to  be  the  time- 
optimal  guidance  law.  However,  Fig.  3  illustrates  why  this  is  usually  not  the  case. 
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Figure  3.  Pursuit  and  Proportional  Navigation  of  a  5.5  Meter  Per  Second  Chaser  Vehicle 

Intercepting  a  6  Meter  Per  Second  Target  Vehicle 

A  constant-velocity  target  vehicle  moving  at  6  meters  per  second  on  a  constant 
southeasterly  course  and  speed  is  to  be  intercepted  by  a  chaser  vehicle  moving  at  5.5 
meters  per  second.  The  chaser  vehicle  departs  the  origin,  once  using  pursuit  guidance 
and  once  using  proportional  navigation,  and  the  positions  of  both  vehicles  are  shown  at  1 
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second  intervals  for  a  total  of  50  seconds.  The  pursuit  guidance  law  initially  closes  range 
more  rapidly,  but  does  not  follow  a  direct  path  to  the  intercept  point.  Instead,  because  of 
the  mismatch  in  speeds  across  the  line  of  sight,  the  target  vehicle  changes  bearing  and 
presents  a  more  opening  aspect  throughout  the  problem.  The  chaser  vehicle  falls  into  a 
“tail  chase”  with  the  target  vehicle  and  closure  rate  drops  significantly.  In  fact,  because 
the  chaser  vehicle  is  slower  than  the  target  vehicle,  range  between  vehicles  eventually 
begins  to  open  and  the  opportunity  to  intercept  is  lost.  Compare  this  to  proportional 
navigation,  which  in  this  case  allows  the  chaser  to  intercept  the  target  vehicle  even 
though  it  is  at  a  speed  disadvantage.  Note  also  that  proportional  navigation  follows  a 
straight-line  path  to  the  intercept  point,  wasting  no  path  length  enroute.  In  fact, 
proportional  navigation  has  been  shown  to  be  the  time  optimal  method  for  intercepting 
constant-velocity  targets  (Mehrandezh,  Sela,  Fenton,  and  Benhabib,  1999). 

Figure  4  illustrates  the  relative  merits  of  these  two  guidance  laws  for  the  next 
level  of  complexity,  the  realistic  case  of  a  constant-speed  maneuvering  target. 
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Figure  4.  Comparing  Proportional  Navigation  and  Pursuit  Guidance,  Maneuvering  Constant 

Speed  Target  (After:  Hutchins  and  Roque,  1995) 
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Here  a  1  meter  per  second  target  vehicle  follows  a  typical  AUV  survey  pattern  composed 
of  parallel  tracks.  A  chaser  vehicle  departs  the  origin  as  before,  using  each  of  the 
guidance  laws.  The  chaser  vehicle’s  speed  is  1.2  meters  per  second,  and  vehicle 
positions  for  480  seconds  are  shown.  In  this  case  proportional  navigation  clearly  results 
in  excessive  path  length  as  the  chaser  vehicle  tracks  the  target  vehicle’s  maneuvers. 
Unlike  the  previous  example,  pursuit  guidance  is  now  superior  to  proportional  navigation 
in  that  interception  occurs  sooner.  However,  pursuit  guidance  is  not  optimal,  as  a  direct 
path  to  the  same  rendezvous  point  and  rendezvous  time  would  have  required  the  chaser 
vehicle  to  travel  at  only  1.0  meters  per  second  thereby  saving  42%  of  the  propulsion 
energy  required  to  reach  the  intercept  point.  Conversely,  had  the  chaser  vehicle  traveled  a 
direct  route  at  1.2  meters  per  second  to  intercept  the  target  vehicle,  it  would  have 
intercepted  it  in  421  seconds,  a  12%  time  savings.  Planning  this  direct  path,  however, 
requires  a  priori  knowledge  of  target  maneuvers. 

Rendezvous  can  be  seen  as  an  extension  of  the  above  discussion,  provided  that 
trajectory  planning  take  into  account  the  final  course  and  speed  changes  required  to 
match  target  vehicle  velocity  as  well  as  position. 

Trajectory  planning  benefits  from  a  priori  knowledge  of  target  vehicle 
movements.  This  is  not  a  valid  assumption  for  much  of  the  previous  intercept  work, 
since  this  work  stems  from  weapons  research  and  therefore  the  target  can  be  expected  to 
attempt  to  evade  the  incoming  interceptor.  However,  in  the  context  of  AUV  rendezvous, 
a  cooperative  behavior  between  vehicles,  it  would  be  a  reasonable  assumption  that  the 
chaser  vehicle  could  be  provided  the  details  of  the  chaser  vehicle’s  mission  prior  to  the 
start  of  the  operation.  This  assumption  will  be  used  in  the  rest  of  this  work  to  optimize 
the  rendezvous  process. 
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III.  TIME-OPTIMAL  RENDEZVOUS 


A.  OPTIMAL  CONTROL  FUNDAMENTALS 

Optimal  control  problems  involve  finding  the  sequence  of  control  inputs  to  drive  a 
system  from  a  prescribed  initial  state  to  a  prescribed  final  state  while  minimizing  a 
specified  performance  index  J(x).  Denoting  the  set  of  control  inputs  as  the  vector  u,  and 
the  states  by  the  vector  x,  the  general  form  of  the  perfonnance  index  is 

‘f 

J(x,u,tf)  =  </>(tf)  +  J  L(x,u,t)dt  (3.1) 

o 

The  term  </>(tf)  is  some  specified  function  of  the  final  state,  and  the  integral  term  is  a 
function  of  states  and  controls  throughout  the  time  period  in  question. 

The  four  necessary  conditions  for  optimality,  derived  using  the  calculus  of 
variations,  are  satisfaction  of  boundary  conditions;  plus 


dH  . 

- =  X 

(3.2) 

dH 

(3.3) 

<9u 

(3.4) 

Where  the  Hamiltonian  H,  defined  as 

H  =  L  +  p*x  (3.5) 

is  a  convenient  grouping  of  terms  resulting  from  the  derivation  of  the  above  conditions. 
It  consists  of  the  integrand  of  the  performance  index,  plus  the  inner  product  of  the  costate 
vector  p  and  the  time  derivative  of  the  state  vector  (Bryson,  1999). 

The  above  assume  that  the  magnitude  of  control  inputs  is  unconstrained. 
However,  in  practical  systems  the  magnitudes  of  control  inputs  are  necessarily 
constrained,  which  can  complicate  solution  of  optimal  control  problems.  Frequently  the 
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optimal  control  solution  obtained  using  the  above  equations  requires  infinite  control 
effort.  For  example,  the  time-optimal  problem  of  finding  the  force  to  be  applied  to  a 
mass  to  accelerate  it  to  a  specified  speed  in  the  minimum  possible  time  has  as  its  solution 
an  infinite  force  over  an  infinitesimal  time  period,  the  integral  of  which  equals  the 
impulse  required  to  change  the  momentum  of  the  mass  the  specified  amount.  Realistic 
systems  with  constraints  on  controls  were  addressed  by  (Pontryagin,  1962),  who 
introduced  the  minimum  principle  as  a  generalization  of  Eq.  3.3  to  specify  that  the 
optimal  control  minimizes  the  Hamiltonian  at  each  instant  of  time,  or 

u  =  argmin(//)  (3.6) 

The  rendezvous  problem  clearly  falls  into  the  category  of  constrained  controls, 
owing  to  the  finite  control  effort  available  to  an  AUV’s  thrusters  and  control  surfaces. 

The  rendezvous  problem  also  falls  into  the  category  of  optimal  control  problems 
with  constraints  on  the  final  state.  Because  the  objective  of  rendezvous  is  for  a  chaser 
vehicle  to  match  the  position  and  velocity  of  a  target  AUV,  the  state  of  the  target  vehicle 
represents  the  specified  final  state  of  the  chaser  vehicle. 

The  final  state  is  not  fixed,  since  the  target  vehicle  is  in  motion.  Instead  there  is  a 
“target  set”  of  states  as  a  function  of  time.  Additionally,  because  the  final  time  for  the 
problem  is  yet  to  be  determined,  this  problem  is  also  classified  as  one  having  an  open 
final  time. 

Finally,  the  rendezvous  problem  will  be  shown  to  have  a  singular  solution. 

B.  THE  AUV  EQUATIONS  OF  MOTION 

The  equations  of  motion  for  the  ARIES  AUV  describe  its  three-dimensional 
dynamics  and  kinematics.  The  pertinent  aspects  of  AUV  rendezvous  involve  motions  in 
the  horizontal  plane,  since  vertical  distances  between  vehicles,  typically  a  few  meters,  are 
insignificant  when  compared  to  horizontal  distances  measured  in  hundreds  or  thousands 
meters.  Because  distance  between  vehicles  is  dominated  by  horizontal  plane  motion,  and 
because  there  is  insignificant  cross-coupling  between  ARIES  horizontal  and  vertical 
plane  motions,  only  the  horizontal  plane  is  addressed  in  this  work.  The  horizontal  plane 
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motions  of  interest  are  steering,  as  controlled  by  the  vehicle’s  rudders,  and  surge,  as 
controlled  by  the  vehicle’s  thrusters. 

1.  Steering  Equations 

The  linearized  equations  of  motion  for  steering  (Healey,  1995)  are  of  the  form: 

Mx  =  Ax  +  Bu  (3.7) 

Where  M  is  the  mass  matrix,  A  is  the  dynamics  matrix,  and  B  is  the  control  distribution 
matrix.  Premultiplying  both  sides  by  M_1  results  in  the  set  of  equations  for  x  in  the 
standard  state-space  form  needed  to  solve  the  optimal  control  problem.  The  ARIES 
equations,  assuming  constant  forward  velocity  u  and  using  values  determined  by 
(Johnson,  2001)  are: 

-0.149  0.890  0¥vl  [  0.153" 

-0.051  -0.411  0  r  +  -0.165  Sr  (3.8) 

0  1  oJL^J  [  o 

The  states  are  v,  r,  and  yr ,  where  v  is  sideslip  velocity  in  meters  per  second,  r  is  yaw  rate 
or  time  derivative  of  vehicle  heading  in  radians  per  second,  and  y/  is  the  vehicle  heading. 
The  control,  8r ,  is  rudder  angle  in  radians. 

2.  Simplification  of  the  Steering  Equations 

In  order  to  examine  the  optimal  control  problem  in  a  tractable  form,  the  steering 
equations  were  simplified  to  a  single  equation.  Of  the  three  state  variables  in  the  steering 
equations,  the  vehicle  heading  i//  is  the  most  significant  in  determining  vehicle  motion. 
Sideslip  velocity  v  is  small  compared  to  vehicle  forward  velocity  u.  Additionally,  yaw 
rate  r  is  the  time  derivative  of  heading  angle  y/ .  It  does  not  significantly  affect  other 
vehicle  motions,  and  its  effects  are  accounted  for  in  yr  . 

Assuming  that  r  reaches  steady  state  early  in  a  turn,  a  reasonable  assumption 
based  on  ARIES  operational  data,  the  steady  state  version  of  second  equation  in  Eq.  3.8 
becomes 

0  =  -0.051V-  0.41  lr-0.165^  (3.9) 
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Operational  experience  shows  that  the  magnitude  of  v  is  generally  less  than  the 
magnitude  of  r  during  a  turn.  This,  coupled  with  the  magnitudes  of  the  coefficients  in  the 
first  two  tenns  on  the  right  hand  side  of  Eq.  3.8,  makes  the  first  term  over  an  order  of 
magnitude  smaller  than  the  second  term.  Disregarding  the  v  term  and  rearranging  the 
above  equation  yields  a  simplified  version  of  equation  (3.7) 

y/  =  r  =  klSi.  (3.10) 

The  result  is  that,  for  constant  speed,  turn  rate  is  proportional  to  rudder  angle  and  the 
vehicle’s  track  in  a  turn  is  approximately  a  circular  arc.  This  is  a  sufficiently  accurate 
approximation  for  the  optimal  control  solution  that  follows. 

Additionally,  over  ARIES  operational  speed  range  its  turning  radius  is 
approximately  constant.  As  a  result,  for  a  given  rudder  angle,  its  turn  rate  is 
approximately  proportional  to  u,  so  for  the  optimal  control  solution, 

y/  =  kuSr  (3.11) 

3.  Surge  Equation 

The  surge  equation  of  motion  describes  the  behavior  of  u  in  response  to 
longitudinal  forces  acting  on  the  vehicle,  namely  propulsive  thrust  and  drag.  Both  are 
quadratic,  with  thrust  proportional  to  the  square  of  thruster  speed  N,  and  drag 
proportional  to  the  square  of  u  (Triantafyllou,  2002).  Taking  into  account  that  ARIES 
always  operates  with  a  positive  values  of  u  and  N,  the  simplified  surge  equation  is 

u  =  ccN2-J3u2  (3.12) 

4.  Kinematics 

The  preceding  equations  of  motion  are  augmented  by  kinematic  relationships 
between  the  state  variables  to  describe  motion  in  the  horizontal  plane.  The  coordinate 
system  used  is  the  “North-East-Down”  system  where  X  is  the  northerly  coordinate 
relative  to  some  global  origin,  Y  is  the  easterly  coordinate,  and  Z  is  the  downward 
coordinate,  all  in  meters.  Since  ^orients  the  vehicle  in  the  horizontal  plane  of  this 
coordinate  system,  and  vehicle  velocity  is  predominantly  in  this  direction  (disregarding 
v),  the  simplified  kinematic  equations  for  the  horizontal  plane  coordinates  are 
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X  =  u  cost// 

Y  =  u  sin  \f/ 

Figure  5  illustrates  these  variables.  The  result  is  a  set  of  four  state  equations 


(3.13) 

(3.14) 
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Figure  5.  AUV  State  Variables 

5.  Result 

The  result  of  the  above  is  the  following  set  of  expressions  for  the  time  optimal 
control  problem.  The  objective  is  to  find  the  sequence  of  control  inputs,  rudder 
commands  8r(t)  and  thruster  speed  commands  N(t),  which  minimize  the  time  until 
rendezvous.  The  performance  measure  is  simply 
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(3.16) 


j  j 

J  =  tf  =  <P( tf  )  +  J  L(x,u,t)dt  =  J 1  dt 


and  the  integrand  in  Eq.  3. 1  is  unity.  The  Hamiltonian  for  this  problem  is  therefore 

H  =  1  +  pJatSr  +  p2ucosy/  +  p3usiny/  +  p4  yaN2  -  =  0  (3.17) 


The  Hamiltonian  equals  zero  whenever  the  Hamiltonian  is  not  an  explicit  function 
of  time  and  the  problem  has  an  open  final  time  (Kirk,  1970).  Substituting  the 
Hamiltonian  into  Eq  3.2  simply  yields  the  state  equations  Eq.  3.8  again.  Substituting 
into  Eq.  3.3  yields  the  following  differential  equations  for  the  costates 


Pi  = 
Pi  = 
P  i  — 

P4  = 


SH 

Sy/ 


u(p2  sin^  -  p3  cos^) 


SH 

SX 

SH 

SY 

SH 

Su 


=  0 
=  0 

=  -plk8r  -  p2  cos  y/  -  p3  sin  y/  +  2  p4fiu 


(3.18) 


Clearly  p2  and  p,  are  constants.  Inserting  these  into  the  first  equation  and  integrating 
yields 

t 

Pi  =  ^(p2u^my/ -  p3uco?,y/)dt  =  p2SY  -  p3AX  +  yy  (3.19) 

o 


which  shows  that  px  has  a  constant  value  along  lines  in  the  horizontal  plane 
corresponding  to 


-1  1 

f  AT  3 

_1 

tan 

=  tan 

IaxJ 

l  Pi, 

(3.20) 


where  AT  and  AX  denote  the  change  in  vehicle  X  and  Y  coordinates  since  the  start  of  the 
problem. 
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C.  TIME-OPTIMAL  SOLUTION  FOR  CONSTANT  SPEED 

As  a  step  towards  determining  the  time-optimal  solution,  we  first  examine  the 
case  of  a  constant  speed  vehicle  transitioning  from  a  prescribed  initial  state  to  a 
prescribed  final  state  in  the  shortest  possible  time.  For  simplicity,  the  value  of  u  is  fixed 
at  1  meter  per  second  and  maximum  magnitude  of  rudder  control  is  fixed  at  1  unit.  With 
no  speed  dynamics  included,  the  final  equation  in  Eq,  3.15  and  3.18  are  removed.  Initial 
vehicle  position  is  at  the  origin,  and  the  rudder  constant  of  proportionality  k  is  left 
unspecified.  The  problem  is  illustrated  in  Fig.  6. 


Figure  6.  Initial  and  Final  Vehicle  Positions 

The  objective  is  move  from  the  initial  state  to  the  final  state  in  the  shortest 
possible  time.  The  turn  radius  p  for  a  vehicle  moving  along  a  circular  arc  at  speed  u  and 
yaw  rate  \j/  is 


u 

P  =  ~ 
V 


(3.21) 
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In  the  limit  as  the  rudder  constant  of  proportionality  k  approaches  infinity;  p  approaches 
zero,  yaw  rate  y/  approaches  infinity  and  this  problem  devolves  to  finding  the  shortest 
transit  between  the  two  points.  At  fixed  speed,  the  solution  is  the  well  known  straight 
line  connecting  two  points  in  Euclidean  space.  This  trajectory  requires  a  constant  course 
between  the  two  points  between  initial  and  final  turns,  which  in  turn  requires  a  constant 
zero  rudder  command.  The  constrained  controls  in  this  example  invoke  Pontryagin’s 
minimum  principle,  which  requires  minimization  of  the  Hamiltonian  at  each  moment  in 
time.  The  Hamiltonian  for  the  constant  speed  case  is 

H  =  \  +  plkSr  +  p2cosy/ +  p3siny/  (3.22) 

and  minimization  involves  finding  the  control  Sr  at  each  moment  that  minimizes  H.  The 
coefficient  ofc5>(. ,  namely  pxk ,  is  know  as  the  “switching  function”  since  minimizing  H 
involves  always  switching  8r  to  its  maximum  value  opposite  in  sign  to  the  switching 
function  to  make  the  value  of  the  complete  tenn  pxk8r  as  small  as  possible  at  every  point 
in  time.  Such  full  application  of  available  control  is  commonly  referred  to  as  “bang”. 

Clearly  the  straight-line  solution  is  not  possible  if  the  rudder  is  not  zeroed. 
Zeroing  the  rudder  occurs  if  the  value  of  the  switching  function  is  zero  itself,  such  that 
rudder  angle  no  longer  directly  affects  the  value  of  the  Hamiltonian.  Such  a  situation  is 
referred  to  as  “singular”,  and  occurs  here  for  /?,  =0.  As  discussed  previously,  straight 
lines  of  constant  px  exist  in  the  plane,  so  the  optimal  control  solution  to  this  problem  has 
the  constants  px  ,  p2 ,  and  p3  set  to  values  which  result  in  p1  =0  on  the  line  between 

these  two  points.  The  solution  is  referred  to  as  “bang-singular-bang”,  a  straight  transit 
between  two  maximum  rudder  turns. 

Because  the  switching  function  equals  zero  on  the  singular  arc,  the  control  history 
for  rudder  commands  cannot  be  determined  as  the  sequence  which  minimizes  the 
Hamiltonian.  Other  means  must  be  employed,  and  one  common  method  is  to  note  that  if 
the  switching  function  is  to  equal  zero  for  the  non-zero  duration  of  the  singular  arc,  its 
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time  derivatives  must  also  equal  zero  during  that  period.  From  Eq.  3.18  the  derivative  of 
the  rudder  switching  function  is 

px  =  p2smy/ -  p^cosy/  (3.23) 

Since  the  only  variable  on  the  right  hand  side  is  y/ ,  it  must  remain  constant  if  px 
is  to  remain  equal  to  zero  such  that  px  remains  constant  and  equal  to  zero.  This  implies 
constant^-,  which  by  Eq.  3.23  implies  zero  rudder  during  the  singular  arc,  as  would  be 
expected. 

As  the  value  of  k  is  reduced  to  reasonable  values,  the  turn  radii  increase  to  finite 
values  and  curved  portions  appear  on  the  ends  of  the  trajectory.  However,  the  fonn  of  the 
solution  is  unchanged.  The  situation  is  illustrated  in  Fig.  7.  The  singular  arc  still  exists 
in  the  middle  of  the  trajectory,  along  a  new  line  of  px=  0  as  determined  by  the  problem 
boundary  conditions. 


Figure  7.  Time  Optimal  Trajectory,  Constant  Speed 
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This  result  is  continued  by  work  on  Dubins  sets  in  the  field  of  optimal  path 
planning  (Shkel  and  Lumelsky,  2001).  This  work  involves  finding  the  shortest  possible 
path  between  two  points  when  each  point  has  an  associated  heading,  with  a  maximum 
limit  imposed  on  path  radius  of  curvature.  These  conditions  equate  to  the  boundary 
conditions  and  control  constraints  of  the  previous  problem.  The  optimal  path  of  shortest 
distance,  in  cases  when  the  distance  between  the  two  points  was  large  compared  to  the 
radius  of  curvature,  is  a  trajectory  consisting  of  a  minimum-radius  curve  followed  by  a 
straight  segment  followed  by  a  minimum  radius  curve.  The  Dubins  result  is  shown  in 
Fig.  8. 


Figure  8.  Dubins  Solution 

D.  TIME-OPTIMAL  SOLUTION  FOR  VARIABLE  SPEED 

Having  characterized  the  time-optimal  rudder  control,  the  problem  is  now 
generalized  to  include  variable  vehicle  speed.  The  problem  is  illustrated  in  Fig.  9,  where 
all  four  vehicle  states  apply  and  the  vehicle  goes  from  zero  initial  speed  to  a  final  speed 
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Figure  9.  Initial  and  Final  States,  Variable  Speed 

The  variable-speed  Hamiltonian  is 

H  =  \  +  u(plkSr  +  p2cosi//  +  p2sini//)  +  p4 \jxN2  -/?w2]  (3.24) 

The  Hamiltonian  is  now  to  be  minimized  by  the  action  of  two  controls,  the  rudder  angle 
Sr  and  thruster  speed  N.  Note  that  since  thruster  speed  is  a  squared  term  and  the  speed 
switch  is  pA ,  the  Hamiltonian  is  minimized  by  maximizing  thruster  speed  whenever 
pA< 0  and  by  stopping  thrusters  when  p4> 0.  Initially,  since  uj  =0  and  H=0,  pA  must  be 

less  than  zero  and  full  thruster  speed  is  ordered  to  set  the  vehicle  in  motion.  As  the 
vehicle  begins  to  move  and  turn,  the  middle  tenn  responds  as  it  did  in  the  constant-speed 
case  to  minimize  the  Hamiltonian.  The  path  is  identical  to  the  constant  speed  case. 

The  speed  switching  function  is pA,  which  starts  negative.  From  Eq.  3.18,  its 
dynamics  are  governed  by 
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p4  =  -pxk8r -  p2  cos y/  —  p3 sin^  +  2 p4fiu 


(3.25) 


Since  the  Hamiltonian  equals  zero  at  all  times,  Eq.  3.22  shows  that  the  sum  of  the  first 
three  terms  on  the  right  hand  side  are  equal  to  1 .  With  p4<  0  initially,  and  u=0,  the  last 

tenn  starts  equal  to  zero  and  goes  negative.  As  a  result,  p4  starts  negative  and  begins 
increasing.  Were  it  to  go  positive  it  will  stay  positive.  There  are  two  possible  outcomes. 
In  the  first,  the  last  term  goes  negative  fast  enough  that  p4  never  goes  positive.  In  this 

case  full  thruster  speed  is  ordered  continuously.  In  the  second,  p4  eventually  goes 
positive  and  zero  thruster  speed  is  therefore  ordered  to  minimize  the  Hamiltonian.  The 
latter  case  corresponds  to  the  vehicle  accelerating  to  as  high  a  speed  as  possible  to 
minimize  transit  speed,  then  decelerating  to  meet  the  tenninal  constraint  on  speed,  as 
would  be  expected  in  satisfying  the  boundary  conditions  of  this  problem.  This  speed 
control  is  “bang-bang”,  full  speed  command  followed  by  zero  speed  command.  The 
former  case  would  correspond  to  a  case  where  transit  time  is  minimized  and  target 
vehicle  speed  equals  maximum  chaser  vehicle  speed. 

E.  SOLUTION  FOR  MOVING  TARGET  BY  NUMERICAL  METHOD 

The  above  results  provide  the  general  characteristics  of  the  solution  to  the  time- 
optimal  control  problem  for  a  stationary  target  vehicle.  Because  of  the  general  difficulty 
in  obtaining  solutions  to  optimal  control  problems,  a  numerical  method  was  used  to 
verify  that  the  solution  for  the  more  general  case  of  rendezvous  with  a  moving  target  was 
the  same. 

The  analysis  was  done  using  the  MATLAB  FMINCON  constrained  optimizer. 
An  initial  state  was  defined  for  the  vehicle,  as  was  a  target  set  of  final  states.  Parameters 
to  be  optimized  were  rudder  and  thruster  commands.  Thruster  and  rudder  commands 
were  discretized  into  50  steps  each,  for  100  total  control  inputs.  One  additional 
parameter  to  be  detennined  was  the  size  of  the  time  step,  for  a  total  of  101  parameters. 
The  FMINCON  optimizer  then  determined  the  values  of  these  parameters  which  resulted 
in  the  smallest  step  size,  hence  the  earliest  rendezvous  time,  subject  to  the  constraint  that 
the  final  state  of  the  vehicle  matched  target  vehicle  state.  Each  thruster  and  rudder 
command  was  optimized  individually  to  arrive  at  the  earliest  possible  time  at  which 
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vehicle  states  were  matched.  The  chaser  vehicle  started  at  the  origin  on  course  North 
(^=0)  and  speed  =  1.0  meters  per  second.  The  target  vehicle  started  at  (100,0)  on  a 
southeasterly  course  ( i//  =0.75  n )  at  speed  =  1 .0  meters  per  second.  Turn  dynamics  are 

W  =  8r  (3.26) 

and  surge  dynamics  are 

u  =  0.0SN2  -O.OSu2  =  0.0S(u2com  -  u2)  (3.27) 

where  ucom  represents  speed  command  expressed  in  meters  per  second  vice  thruster  speed 
in  RPM.  Control  constraints  limited  the  magnitude  of  rudder  angle  limited  to  0.4  radians 
and  speed  to  a  maximum  of  1.5  meters  per  second.  These  provide  chaser  vehicle 
dynamics  similar  to  ARIES. 

The  problem  and  results  are  shown  in  Fig.  10  through  12. 


Figure  10.  Vehicle  Tracks,  MATLAB  FMINCON  Time-Optimal  Rendezvous  Solution 
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Figure  1 1 .  Control  Histories,  MATLAB  FMINCON  Time-Optimal  Rendezvous  Solution 


Rendezvous  @  55.75  Seconds 


Figure  12.  Speed  and  Heading,  MATLAB  FMINCON  Time-Optimal  Rendezvous  Solution 
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Figure  1 1  shows  the  control  histories  for  this  problem.  As  discussed  previously, 
rudder  control  was  “bang-singular-bang”,  with  maximum-effort  initial  and  final  turns 
separated  by  a  singular  arc  where  rudder  is  essentially  zero  except  for  fluctuations  due  to 
the  singular  nature  of  this  part  of  the  problem.  Except  for  one  point  affected  by 
discretization  error,  speed  control  was  “bang-bang”.  The  chaser  vehicle  accelerated  to 
maximum  speed  and  maintained  maximum  speed  as  long  as  possible,  shortening  the  time 
until  rendezvous.  At  the  speed  switch  zero  speed  was  ordered,  decelerating  the  vehicle  at 
the  maximum  possible  rate  such  that  vehicle  speed,  course  and  position  were  matched 
simultaneously. 

F.  EXISTENCE  AND  UNIQUENESS  OF  THE  SOLUTION 

Existence  and  uniqueness  of  the  time-optimal  solution  can  be  addressed  by 
considering  two  sets  of  vehicle  states.  The  set  of  all  possible  chaser  vehicle  states  begins 
as  a  single  point  in  its  state  space,  its  initial  condition,  and  grows  as  a  function  of  time 
according  to  the  vehicle’s  control  history  during  the  time  interval.  This  “set  of  reachable 
states”  (Kirk,  1970),  is  defined  for  each  future  point  in  time.  The  target  vehicle  also  has  a 
set  of  reachable  states,  but  if  we  assume  that  it  follows  a  pre-specified  trajectory  without 
error  its  set  of  reachable  states  at  any  time  is  simply  the  point  it  is  scheduled  to  occupy  at 
that  time.  Figure  13  illustrates  this,  showing  the  initial  and  possible  future  positions  of 
both  vehicles  at  future  points  in  time,  position  being  a  subspace  of  the  state  space. 
Clearly  no  rendezvous  is  possible  if  the  target’s  state  is  not  a  point  in  the  chaser  vehicle’s 
set  of  reachable  states.  The  time  at  which  the  target  vehicle’s  future  position  is  first 
included  in  the  chaser  vehicle’s  set  of  reachable  positions  is  the  first  candidate  for  time- 
optimal  rendezvous,  although  all  other  states  must  be  matched  as  well  if  rendezvous  is  to 
be  feasible.  The  envelope  of  chaser  vehicle  reachable  positions  is  defined  by  its 
maximum  travel  from  its  initial  position  by  that  time,  which  is  detennined  primarily  by 
its  maximum  speed.  Generalizing  this  to  include  all  states,  the  earliest  time  for  which  the 
target  vehicle’s  state  is  included  in  the  chaser  vehicle’s  set  of  reachable  states  is  the 
earliest  time  that  rendezvous  is  possible.  This  defines  the  time-optimal  rendezvous 
solution. 
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Assuming  the  chaser  vehicle  has  a  speed  advantage  over  the  target  vehicle,  the 
solution  exists.  For  no  solution  to  exist  the  target  vehicle  must  remain  outside  the  chaser 
vehicle’s  set  of  reachable  states  for  all  times,  which  occurs  only  if  its  speed  exceeds  the 
chaser  vehicle,  thereby  keeping  it  outside  of  the  chaser  vehicle’s  ever-expanding  set  of 
reachable  states.  The  assumption  of  speed  advantage  is  logical.  If  chaser  vehicle  speed 
did  not  at  least  equal  target  speed,  it  could  not  match  speed  with  the  target  and  therefore 
could  not  rendezvous  with  it. 

If  the  solution  exists,  it  is  unique.  This  is  so  because  the  target  vehicle  occupies 
exactly  one  position  at  any  given  time,  and  the  time  to  rendezvous  is  a  monotonically 
increasing  function  of  target  progress  down  track.  Were  multiple  solutions  to  exists,  each 
would  be  at  a  different  position  and  time.  Since  the  value  of  each  time  is  unique,  one 
would  have  a  unique  lower  value  than  the  others  and  would  therefore  be  a  unique  time- 
optimal  solution. 


Target  Vehicle 
Initial  Position 


Target  Track 


Chaser  Vehicle 
Set  of  Reachable  Positions 
t=t, 


Chaser  Vehicle 
Set  of 
Reachable  Positions 
t=t0 


Chaser  Vehicle  Initial  Position 


Figure  13.  Reachable  Positions  for  Chaser  and  Target  Vehicles 
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G.  SUMMARY 

The  results  of  this  chapter  indicate  that  the  time  optimal  control  history  for  AUV 
rudder  is  “bang-singular-bang”:  a  maximum-effort  turn  towards  the  rendezvous  point, 
followed  by  a  zero-rudder  constant  heading  transit  towards  the  rendezvous  point, 
followed  by  another  maximum-effort  turn  into  rendezvous.  Speed  control  is  “bang- 
bang”:  immediate  maximum-effort  acceleration  to  maximum  speed,  followed  by  a  zero- 
propulsion  maximum  deceleration  to  match  target  speed  at  the  rendezvous  point.  Control 
histories  such  as  these  can  be  implemented  practically  in  the  ARIES  vehicle. 
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IV.  ENERGY-OPTIMAL  RENDEZVOUS 


A.  OVERVIEW 

Along  with  situations  requiring  timely  rendezvous  are  situations  requiring  energy- 
efficient  rendezvous.  Present  AUVs  are  energy  limited,  with  the  vast  majority  powered 
by  electric  batteries.  Propulsion  is  the  largest  demand  on  an  AUV’s  energy  stores,  a  fact 
driving  the  development  of  long-duration  glider  vehicles.  Propulsion  demands  on  a 
server  vehicle  operating  in  a  network  of  multiple  sensor  vehicles  spread  over  a  large  area 
would  be  significant.  In  order  to  conserve  server  vehicle  energy  reserves,  thereby 
extending  its  time  on  station,  it  would  be  advantageous  to  plan  the  rendezvous  trajectory 
to  be  as  energy-efficient  as  possible.  This  chapter  detennines  the  characteristics  of 
energy-optimal  AUV  rendezvous. 

B.  AUV  POWER  CHARACTERISTIC 

The  same  approach  as  the  previous  chapter  is  used  here,  with  the  same  necessary 
condition  for  optimality.  The  difference  for  energy  optimality  is  the  cost  function,  which 
here  is  the  total  energy  required  for  rendezvous,  defined  as  the  integral  of  power  over 
time. 

The  AUV  power  characteristic  is  the  sum  of  two  terms:  “hotel”  loads  and 
propulsion  loads.  Hotel  loads  are  those  which  are  approximately  constant  over  time,  such 
as  power  for  computers  and  sensors.  Propulsion  loads  are  those  required  to  power  the 
vehicle’s  main  thrusters,  and  are  proportional  to  the  product  of  thrust  and  vehicle  speed. 
Since  thrust  is  approximately  proportional  to  the  square  of  thruster  speed,  and  steady  state 
vehicle  speed  is  proportional  to  thruster  speed  (Triantafyllou  and  Hover,  2002),  a 
reasonable  relationship  for  vehicle  power  requirements  is 

P  =  A  +  BN2u  (4.1) 

where  P  is  power  in  watts,  A  is  hotel  load  in  watts,  B  is  the  propulsion  power  coefficient, 
and  u  is  present  vehicle  speed.  N  is  thruster  speed  command  expressed  as  steady-state 
vehicle  speed  in  meters  per  second.  In  steady  state  this  becomes 

P  =  A  +  BNi  =  A  +  Bu 3  (4.2) 
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To  define  the  cost  function  for  the  ARIES  vehicle,  its  values  of  A  and  B  had  to  be 
determined.  This  was  done  by  installing  an  electrical  current  sensor  in  its  power  circuitry 
and  logging  vehicle  power  requirements  as  a  function  of  speed,  including  zero-speed 
measurements  of  hotel  loads.  The  data  is  shown  in  Fig  14. 


Figure  14.  ARIES  Power  Characteristic 

Fitting  the  parameters  A  and  B  to  this  data  and  substituting  into  Eq.  4.2  yields,  for 
steady  state  operation 

P  =  147.0  + 1 79. 1 u  =  147.0  + 1 79. 1 A3  (4.3) 

C.  USABLE  SPEED  RANGE 

Figure  14  shows  that  power  measurements  were  taken  for  conditions  of  no 
propulsion  and  for  propulsion  in  the  upper  end  of  ARIES’  speed  range.  The  lack  of  data 
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between  0  and  0.7  meters  per  second  is  due  to  a  practical  limit  on  minimum  speed  for 
ARIES  and  many  other  AUVs. 

Low-speed  operation  is  restricted  by  vehicle  control  considerations.  Vehicles 
such  as  ARIES  that  use  control  surfaces  vice  thrusters  to  maintain  attitude  and  depth 
require  forward  speed  through  the  water  to  generate  control  surface  forces.  Below  a 
minimum  threshold  speed  vehicle  control  is  lost,  so  operations  are  limited  to  speeds 
greater  than  this  threshold. 

A  more  significant  effect  is  the  tendency  to  ballast  AUVs  to  be  positively 
buoyant,  a  practice  that  assures  eventual  return  to  the  surface  and  vehicle  recovery  in 
nearly  all  circumstances.  This  is  particularly  desirable  considering  the  cost  and 
complexity  of  typical  AUVs.  Any  deviation  from  neutral  buoyancy  introduces  a  buoyant 
force  that  must  be  overcome  by  forces  generated  by  control  surfaces,  which  is  not 
possible  below  a  certain  threshold. 

Finally,  surface  suction  forces  exist  which  tend  to  keep  the  vehicle  surfaced  until 
sufficient  control  surface  forces  are  generated  to  overcome  suction  and  the  vehicle  is  able 
to  dive.  This  occurs  both  at  the  start  of  the  vehicle’s  run  and  whenever  the  vehicle 
returns  to  the  surface  to  obtain  a  GPS  fix. 


The  result  of  the  above  is  a  constraint  on  energy-optimal  solutions  that  vehicle 
speed  be  no  less  than  the  vehicle’s  lowest  controllable  speed.  Based  on  ARIES 
operational  experience,  this  was  established  at  1  meter  per  second. 

D.  MOST  EFFICIENT  SPEED 

A  key  aspect  of  finding  the  energy-optimal  rendezvous  trajectory  is  to  identify  the 
most  efficient  speed.  A  common  definition  of  most  efficient  speed  is  the  speed  for  which 
the  greatest  distance  is  covered  per  unit  energy  expended.  For  vehicles  having  a  power 
characteristic  in  the  form  of  Eq.  4.1,  the  solution  (Bongiomo,  1967)  is 


u  = 


A_ 

\2Bj 


(4.4) 
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However,  this  is  solution  applies  to  transits  of  unspecified  length  or  transit  to  a 
fixed  end  point,  which  in  this  context  equates  to  rendezvous  with  a  stationary  target.  For 
rendezvous  with  a  moving  target  it  is  necessary  to  generalize  the  solution. 

The  energy  optimal  rendezvous  with  a  moving  AUV  must  take  into  account  the 
effect  of  the  target’s  movement  on  energy  requirements.  Figure  15  shows  the  initial 
positions  of  ARIES  and  a  target  vehicle,  as  well  as  the  future  positions  of  the  target 
vehicle  as  a  function  of  time. 


Target  Future 
Positions 


t=13 


t=19  o 

I 


Target  Initial 


Figure  15.  Target  Positions  and  Ranges  as  a  Function  of  Time,  With  Decomposition  of 

Target  Velocity  ut  Into  Components  Across  (ut  )  and  Into  (ut )  the  Line  of  Sight 


Each  future  target  position  is  a  candidate  rendezvous  point,  with  a  candidate 
rendezvous  time  tr .  Each  future  position  has  a  range  R  associated  with  it,  which  is  the 

distance  from  ARIES’  initial  position  to  that  point.  Unlike  the  time-optimal  case,  where 

the  optimal  rendezvous  point  was  simply  the  earliest  point  for  which  rendezvous  is 

36 


possible,  the  location  of  energy-optimal  rendezvous  point  is  less  obvious.  Assuming  that 
ARIES  travels  to  the  rendezvous  point  along  a  straight  path  at  constant  speed u(tr) , 
defined  as 

«(0  =  —  (4-5) 

K 

Figure  15  shows  that  the  value  of  u(tr  )  for  the  earliest  points  will  be  extremely  large,  as 
the  values  of  tr  are  small.  Disregarding  the  curved  ends  of  ARIES  rendezvous  trajectory 
for  the  moment,  the  energy  E  required  to  rendezvous  at  target’s  position  at  time  tr  is 
equal  to  power  times  the  time  available  to  transit  to  that  point,  or 

E{tr)  =  \A  +  Bu(tr)3\  =  d  +  tr  =  Atr  +B~y^-  (4.6) 

V  tr  J  J  tr 


A  necessary  condition  for  the  function  E(  tr )  to  have  a  minimum  is 

mr)  _Q_uBR\tr)\  2R(tr)  |  3dR(tr)~ 

dtr  t2r  tr  dtr 

,  3  dR(0 

dtr 


(4.7) 


One  consequence  of  Eq.  4.7  is  that  the  most  efficient  speed  is  a  function  of 
problem  geometry.  The  final  term  in  the  equation  is  the  target  velocity  component  in  the 
line  of  sight,  or  range  rate.  Compared  to  the  case  of  a  stationary  target  discussed 
previously,  the  most  efficient  speed  for  a  target  with  a  negative  range  rate  or  closing 
target  will  be  lower,  while  the  converse  is  true  for  an  opening  target.  Note  that,  for  zero 
range  rate,  Eq.  4.7  reduces  to  Eq.  4.4. 

A  second  consequence  is  that,  for  the  earliest  rendezvous  opportunity  (time 
optimal  rendezvous),  u{tr)  will  have  its  maximum  value  and  will  drive  Eq.  4.7  strongly 

negative,  getting  less  negative  with  time  as  the  value  of  u(tr )  decreases.  The  result  is  a 
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time  period  early  in  the  problem  during  which  the  energy  required  for  rendezvous 
generally  decreases  if  rendezvous  is  delayed. 

A  third  consequence  is  that  the  minimum-energy  point  can  exist  at  any  time  in  the 
problem,  complicating  the  process  of  finding  it.  The  final  tenn  in  Eq.  4.7  is  determined 
by  the  target’s  heading  and  speed,  both  of  which  can  be  programmed  to  change  at  any 
time.  A  change  from  opening  to  closing  aspect,  as  occurs  attr=3  in  Fig.  15,  will  cause  an 

immediate  drop  in  the  value  of  Eq.  4.7,  which  may  signal  the  opportunity  for  a  new 
minimum,  possibly  a  value  lower  than  previous  minima  depending  on  the  length  of  the 
period  of  closure.  As  a  result,  the  energy-optimal  rendezvous  point  is  more  difficult  to 
locate;  and  the  search  for  it  more  extensive  than  the  time-optimal  case. 

A  related  consequence  is  that  minima  tend  to  be  located  at  points  where  the 
target’s  aspect  changes  from  closing  to  opening.  This  happens  either  when  the  target 
turns  away,  as  occurs  at  tr=8  in  Fig.  15,  or  for  targets  on  straight  paths  as  they  reach  the 

closest  point  of  approach,  as  occurs  at  tr  =19. 

A  computer  simulation  depicted  in  Figs.  16  and  17  demonstrate  the  above  points. 
Figure  16  shows  ARIES  initial  position  southeast  of  a  target  vehicle’s  operating  area. 
ARIES  is  to  rendezvous  with  the  vehicle,  which  is  running  a  typical  AUV  survey  pattern 
along  parallel  tracks  defined  by  waypoints.  The  target’s  speed  is  constant  at  1  meter  per 
second,  and  ARIES  maximum  speed  is  1.5  meters  per  second.  Figure  17  is  a  plot  of 
energy  to  rendezvous  as  a  function  of  rendezvous  time.  For  each  candidate  rendezvous 
point,  the  energy  to  rendezvous  is  calculated  using  Eq.  4.6.  Since  the  curve  is  only 
plotted  for  points  reachable  by  ARIES  at  1.5  meter  per  second  or  less,  most  of  the  points 
prior  to  t=500  seconds  are  not  plotted.  Early  on,  energy  requirements  for  the  first  few 
points  drop  with  increasing  time  as  discussed  above.  The  curve  is  highly  non-linear, 
having  several  maxima  and  minima  caused  by  target  maneuvers,  changes  in  target  aspect, 
and  the  passage  of  time.  The  curve  shows  that,  as  the  target  maneuvers  from  closing  to 
opening  aspect  at  way  point  2,  energy  required  to  rendezvous  begins  to  increase,  with  the 
opposite  occurring  as  it  maneuvers  to  a  closing  aspect  at  way  points  3  and  4. 
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Figure  16.  ARIES  Rendezvous  With  Maneuvering  Target,  Waypoints  Annotated 
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Figure  17. 


Energy  to  Rendezvous,  as  a  Function  of  Time,  With  Way  Points  Annotated 
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Also  plotted  on  Fig.  17  are  two  limits  for  minimum  possible  energy.  The  upper 
line  is  ARIES  minimum  possible  energy  expenditure  assuming  that  it  must  maintain  u 
greater  than  a  minimum  controllable  speed  of  1  meter  per  second.  In  this  case  the  lowest 
power  state  of  the  vehicle  corresponds  to  loiter  or  transit  at  1  meter  per  second.  The 
lower  line  is  the  minimum  possible  energy  expenditure  if  there  were  no  minimum 
controllable  speed.  This  latter  line  represents  a  no-propulsion  vehicle  state,  with  only  the 
hotel  load. 

For  the  minimum  loiter  speed  case,  the  energy-optimal  rendezvous  is  defined  by 
the  point  on  the  rendezvous  energy  curve  to  the  left  of  the  minimum  energy  for  minimum 
loiter  line  that  has  the  lowest  energy  value.  For  this  case,  the  energy-optimal  rendezvous 
occurs  at  way  point  2.  ARIES’  speed  enroute  to  the  rendezvous  point  in  this  case  was 
1.223  meters  per  second.  As  discussed  above,  this  is  a  case  where  a  target  maneuver 
from  a  closing  to  opening  aspect  causes  a  minimum  on  the  energy  curve.  Analysis  of  this 
rendezvous  point  showed  that  it  was  the  point  satisfying  Eq.  4.7.  Rendezvous  is  still 
possible  for  later  times,  such  as  way  points  4  and  later,  but  would  involve  ARIES 
loitering  at  1  meter  per  second  and  using  up  unnecessary  transit  distance  while  waiting 
for  the  rendezvous  at  the  later  point. 

For  the  case  of  no  minimum  loiter  speed,  the  energy-optimal  rendezvous  point  is 
simply  the  global  minimum.  In  this  example,  the  point  occurs  between  way  points  4  and 
5,  and  ARIES  speed  enroute  to  rendezvous  would  have  been  0.487  meters  per  second  if 
there  were  no  ARIES  minimum  speed.  This  is  an  example  of  the  other  case  discussed 
above:  a  minimum  occurring  on  a  steady  course,  where  the  value  of  Eq.  4.7  passes 
through  zero  due  to  the  gradual  change  in  target  vehicle  aspect  as  it  proceeds  down  track. 

Note  that  the  target  maneuver  at  way  point  3  created  a  global  minimum.  Had  the 
target  not  maneuvered  and  remained  on  its  northerly  course,  the  global  minimum  would 
have  occurred  at  way  point  2.  This  illustrates  how  the  energy-optimal  rendezvous  point 
is  highly  dependent  on  the  specifics  of  the  target’s  track,  and  the  necessity  of  examining  a 
large  portion  of  its  track  to  identify  the  energy-optimal  rendezvous  point. 
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Note  also  that  for  the  minimum  loiter  speed  case  that  the  latest  possible  energy- 
optimal  rendezvous  is  the  first  intersection  of  the  energy  curve  with  the  minimum  energy 
for  minimum  loiter  line.  This  is  so  because  the  line  has  a  positive  slope,  therefore  any 
rendezvous  after  this  intersection  must  involve  a  greater  amount  of  energy. 

Finally,  note  that  in  this  case  of  a  constantly  maneuvering  target  that  its 
geographic  position  does  not  change  quickly;  it  tends  to  remain  in  the  same  geographic 
area  and  proceed  slowly  to  the  east.  As  a  result,  the  energy  required  to  rendezvous 
quickly  converges  to  the  hotel  load. 

E.  CHARACTERISTICS  OF  THE  ENERGY-OPTIMAL  SOLUTION 

The  preceding  assumed  ARIES  trajectory  to  rendezvous  was  a  straight  line, 
disregarding  the  effects  of  initial  and  final  course  and  speed  changes  necessary  to 
complete  an  actual  rendezvous  trajectory  as  discussed  in  the  previous  chapter.  The  same 
methods  used  in  the  previous  chapter  are  applied  here  to  determine  the  characteristics  of 
the  energy-optimal  rendezvous  trajectory.  What  differentiates  the  two  is  the  cost  function 

Proceeding  as  with  the  time-optimal  case,  the  cost  function  for  the  energy- 
optimal  case  is  the  total  energy  to  rendezvous.  The  problem  still  features  constraints  on 
controls  and  final  state,  which  is  still  defined  as  a  target  set  since  final  time  is  still  open. 
It  will  also  be  shown  to  be  singular. 

The  cost  function  is  the  integral  of  power  over  time,  or 

lf  <r 

J(x,u,tf )  =  </>(tf)  +  J  L(x,u,t)dt  =  ^A  +  BN2u^it  (4.8) 

0  0 

Using  this  integrand  to  form  the  Hamiltonian  yields 

H  =  ^A  +  BN2u~^  +  pxn5r  +  p2ucosy/  +  p2usm\//  +  p4(aN2  -  J3u2) 

=  (Bu  +  ap4)N2  +  p1uSr  +  A  +  p2ucosi//  +  p3u s'mt//  -  p4/3u2  (4.9) 

=  0 

The  speed  switching  function  is 
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( Bu  +  ap4 ) 


(4.10) 


Bongiono  (1967)  showed  that  speed  control  for  a  non-maneuvering  vehicle  was  singular, 
and  that  its  value  was  provided  by  Eq.  4.4,  the  most  efficient  speed  for  that  case.  It  is 
also  singular  here  as  well,  when  Eq.  4.10  equals  zero.  This  is  expected  since  energy- 
optimal  rendezvous  should  involve  operation  at  speeds  other  than  extremes. 
Substituting  the  Hamiltonian  into  the  necessary  conditions  for  optimality  yields 


P\  = 

Pi  = 

Pi  = 

Pa  ~ 


SH 
Si/ f 


u(p2  simp-  p3  cos^) 


SH 

SX 

SH 

SY 

SH 

Su 


=  0 
=  0 


=  -BN1 


pxkSr  -  p2  cos  \p  -  p3  sin  y/  +  2 p4Pu 


(4.11) 


Again,  as  in  Ch.  Ill,  p2  and  p3  are  constants.  And  again,  px  has  a  constant  value  along 
lines  in  the  horizontal  plane.  So  rudder  control  is  “bang-singular-bang”  in  the  energy- 
optimal  case  as  well.  Speed  control  is  now  “bang-singular-bang”,  with  N 2  driven  to 
zero  for  positive  values  of  the  switching  function,  maximum  for  negative  values  of  the 
switching  function,  and  the  most  efficient  speed  when  the  switching  function  equals  zero. 
F.  NUMERICAL  SOLUTION 

The  same  scenario  run  in  Ch.III  was  run  for  the  energy-optimal  case.  The  results 
are  shown  in  Figs.  18  through  20.  Rudder  and  speed  control  are  “bang-singular-bang”. 
Starting  from  an  initial  speed  of  1.0  meters  per  second,  the  initial  speed  order  is 
essentially  zero  for  the  first  time  step,  decelerating  the  vehicle  to  0.876  meters  per 
second.  Speed  command  is  held  there  until  the  final  time  step  before  rendezvous,  where 
it  is  increased  to  match  target  speed  of  1 .0  meters  per  second  at  rendezvous,  which  occurs 
at  88.76  seconds. 
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Figure  18.  Vehicle  Tracks,  MATLAB  FMINCON  Solution  to  Energy-Optimal  Rendezvous 
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Figure  19.  Control  Histories,  MATLAB  Solution  to  Energy-Optimal  Rendezvous 
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Rendezvous  @  88.76  Seconds 
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Figure  20.  Speed  and  Heading,  MATLAB  Solution  to  Energy-Optimal  Rendezvous 


G.  EXISTENCE  AND  UNIQUENESS  OF  THE  SOLUTION 

As  was  the  case  in  Ch.  Ill,  the  rendezvous  solution  exists  when  the  chaser  vehicle 
has  a  speed  advantage  over  the  target. 

The  solution  is  not  necessarily  unique,  however.  Considering  Fig.  17,  it  is 
possible  that  target  vehicle  maneuvers  could  produce  several  identical  energy  minima.  In 
such  cases,  considering  the  nature  of  rendezvous  operations,  it  would  be  advantageous  to 
select  the  earliest  such  minimum.  This  will  be  the  approach  taken  for  implementation  in 
ARIES. 

H.  SUMMARY 

Energy-optimal  rendezvous  involves  “bang-singular-bang”  control  of  both  rudder 
and  speed.  The  shape  of  the  trajectory  is  similar  to  the  time-optimal  track,  with 
maximum-rudder  initial  and  final  segments  bracketing  a  straight  singular  section.  A 
singular  arc  is  also  contained  in  the  speed  control  history,  where  the  speed  commanded  is 
the  most  efficient  speed  for  the  particular  problem. 
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V.  IMPLEMENTATION  OF  AUV  RENDEZVOUS 


A.  OVERVIEW 

The  time  optimal  and  energy  optimal  AUV  rendezvous  trajectories  derived  in  Ch. 
Ill  and  IV  were  implemented  in  the  NPS  ARIES  vehicle,  a  test  bed  for  investigating  new 
AUV  capabilities  and  behaviors.  Originally  designed  to  serve  as  a  communications  node 
for  a  network  of  AUVs,  it  was  well  suited  for  this  demonstration. 

The  essential  aspects  of  the  optimal  control  solutions  obtained  in  the  previous 
chapters  were  adapted  for  implementation  in  ARIES,  with  modification  to  provide  the 
necessary  efficiency  and  robustness  for  this  implementation. 

B.  IMPLEMENTATION  OF  OPTIMAL  CONTROLS 

The  previously-derived  optimal  controls  solutions  can  be  summarized  as  a  set  of 
rules  which  a  planning  process  must  observe  in  order  to  approximate  the  optimal  controls 
for  AUV  rendezvous.  For  time  optimal  rendezvous,  the  rules  are: 

-  Bang-bang  speed  control:  Accelerate  immediately  to  maximum  speed,  holding 
maximum  speed  as  long  as  possible  without  overshooting  the  final  rendezvous  state, 
decelerate  using  minimum  propulsive  power  to  match  target  speed  when  both  vehicles 
arrive  simultaneously  at  the  arrival  point. 

-  Bang-singular-bang  rudder  control:  Immediately  make  an  initial  maximum- 
rudder  turn  to  the  closing  course,  maintain  constant  course  (zero  rudder)  as  long  as 
possible  without  overshooting  the  final  rendezvous  state,  then  make  a  final  maximum- 
rudder  turn  to  rendezvous  course,  timed  to  match  target  course  when  both  vehicle  arrive 
simultaneously  at  the  arrival  point. 

For  energy-optimal  rendezvous  the  rules  are: 

-  Bang-singular-bang  speed  control:  Immediately  change  speed  to  the  most 
efficient  speed  for  the  scenario,  hold  this  speed  as  long  as  possible  without  overshooting 
the  final  rendezvous  state,  then  change  speed  to  match  target  speed  when  both  vehicles 
arrive  simultaneously  at  the  arrival  point. 

-  Bang-singular-bang  rudder  control:  Same  as  time-optimal  case. 
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These  essential  aspects  of  the  optimal  control  solutions  were  implemented  in  the  ARIES 
mission  planning  process.  In  order  to  avoid  convergence  problems  and  to  conserve 
ARIES’  computational  resources,  the  ARIES  planning  process  was  not  written  as  a  large- 
dimension  parameter  optimizer  as  was  used  in  Ch.  Ill  and  IV.  Instead,  these  aspects  of 
the  optimal  solutions  formed  a  set  of  rules  to  be  observed  by  a  trajectory  planning  routine 
which  applied  them  in  searching  for  the  minimum-time  or  minimum-energy  rendezvous 
trajectory  for  the  vehicle  states  at  the  time  of  planning. 

The  previously-derived  optimal  controls  represent  typical  solutions  to  such 
optimal  control  problems:  determined  by  the  initial  state  of  the  system,  the  parameters  of 
the  system,  and  perfect  information  about  both.  Such  solutions  are  completely 
determined  at  the  start  of  the  problem.  For  a  given  system,  the  trajectory  is  determined 
by  the  initial  conditions  and  no  adjustment  or  feedback  is  required  during  the  problem 
run,  hence  the  “single  sample”  or  “open-loop”  description  of  such  problems.  The  AUV 
optimal  controls  previously  presented  do  not  account  for  such  real-world  phenomena  as 
imperfect  target  and  chaser  vehicle  state  information,  such  as  courses,  speeds,  and 
positions.  Nor  do  they  account  for  unpredictable  disturbances  such  as  variations  vehicle 
dynamics  parameters  or  currents  and  weather.  These  effects  cause  the  optimal  control 
solution  to  degrade  over  time  as  errors  propagate,  disturbances  affect  the  system,  and 
updated  infonnation  becomes  available.  To  counter  these  degradations,  it  is  necessary  to 
periodically  re-evaluate  the  status  of  the  rendezvous  and  to  replan  it  based  on  updated 
information. 

C.  CONCEPT  OF  OPERATIONS 

In  order  to  proceed  with  development  and  implementation  of  the  rendezvous 
behavior,  it  was  first  necessary  to  establish  several  planning  assumptions  to  guide 
software  development.  They  specify  realistic  constraints  to  be  addressed  in  rendezvous 
software. 

1.  Network  Comprised  of  One  Server  and  Multiple  Sensor  Vehicles 

One  server  vehicle  acts  as  a  central  communications  node  for  a  network  of  sensor 
vehicles.  It  downloads  data  from  these  vehicles  during  rendezvous,  and  later  uploads 
this  data  to  the  next  communications  node.  The  area  of  operations  is  divided  into  zones. 
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Each  zone  contains  one  sensor  vehicle,  carrying  a  sensor  payload  used  to  gather  the 
desired  data  in  this  zone.  Examples  of  such  data  include  locations  of  threats  such  as 
mines  or  obstacles,  or  time-sensitive  information  on  the  activities  of  an  opposing  force. 

2.  Server  Vehicle  Knowledge  of  Sensor  Vehicle  Mission 

Assuming  the  same  operator  controls  all  vehicles  in  the  network,  it  is  reasonable 
to  assume  that  essential  elements  of  the  sensor  vehicles’  mission  can  be  made  available  to 
the  server  vehicle  prior  to  the  start  of  the  operation.  Such  information  includes  positions 
of  intended  waypoints  and  vehicle  speed  along  each  mission  leg.  This  is  data  that  would 
not  be  expected  to  change  during  the  operation,  and  providing  such  data  to  the  server 
vehicle  a  priori  reduces  the  amount  of  data  that  must  be  communicated  between  vehicles 
to  plan  a  rendezvous.  Other  aspects  of  the  mission,  such  as  actual  target  vehicle  position, 
might  vary  in  response  to  effects  such  as  currents  and  other  uncertainties.  As  a  result, 
some  information  must  be  exchanged  between  vehicles  in  order  to  rendezvous. 

3.  Default  Server  Vehicle  State  =  Loiter 

The  server  vehicle  loiters  in  a  specific  location.  When  pursuing  a  rendezvous  it 
departs  the  loiter  area  for  the  operating  area  of  one  or  more  sensor  vehicles,  and  returns  to 
the  loiter  area  once  all  rendezvous  are  complete.  This  allows  selecting  a  loiter  area  to 
optimize  communications  and  transit  paths  between  vehicles. 

4.  Minimal,  Dual-Mode  Communications 

Covertness,  as  well  as  reducing  network  traffic,  requires  minimizing  the  volume 
of  inter-vehicle  communications.  This  is  achieved  through  a  dual-mode  communications 
scheme.  A  command-and-control  mode  consisting  of  a  long-range,  high-reliability,  low 
data  rate  mode  is  used  for  long-range  communications  between  vehicles  to  request  and 
coordinate  the  rendezvous  process.  The  volume  and  length  of  these  transmissions  is 
minimized  to  improve  covertness  and  to  minimize  network  traffic.  A  rendezvous  mode 
consisting  of  a  short-range,  high  data  rate  mode  is  used  during  rendezvous  to  pass  data 
from  sensor  to  server  vehicle.  The  short-range  nature  of  this  mode  provides  covertness. 

5.  Rendezvous  in  Response  to  Sensor  Vehicle  Request 

The  server  vehicle  will  rendezvous  with  sensor  vehicles  in  response  to  their 
requests,  as  opposed  to  rendezvous  with  sensor  vehicles  on  a  pre-determined  schedule. 

Requests  are  transmitted  by  sensor  vehicles  when  their  logic  indicates  that  a  significant, 
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time-sensitive,  reportable  event  has  occurred.  This  scheme  simplifies  server  vehicle 
operations  in  that  it  minimizes  server  vehicle  movements,  reducing  total  propulsion 
energy  required.  Also,  if  the  loiter  area  optimizes  communications,  loitering  in  this  area 
except  when  conducting  rendezvous  improves  the  likelihood  that  the  vehicle  will  be  in 
this  location,  thereby  improving  communications  reliability. 

6.  Vehicle  Network  Operates  Asynchronously 

Because  the  server  vehicle  responds  to  rendezvous  requests  from  sensor  vehicles, 
which  may  request  rendezvous  at  any  time,  the  network  necessarily  is  asynchronous.  The 
handling  of  rendezvous  requests  in  server  vehicle  software  must  ensure  that  requests  are 
properly  queued  and  that  information  contained  in  queued  requests  is  updated  when 
updates  become  available. 

7.  Sensor  Vehicle  Does  Not  Maneuver  for  Rendezvous 

Sensor  vehicles  perform  their  missions  throughout  the  operation  of  the  vehicle 
network,  including  rendezvous  for  data  transfer.  The  sensor  vehicle  does  not  deviate 
from  its  mission  profile  to  facilitate  the  rendezvous.  The  server  vehicle  perfonns  all 
rendezvous  calculations  and  maneuvers  to  satisfy  the  rendezvous  optimization  objective. 
An  important  implication  of  this  is  that  the  sensor  vehicle’s  speed  must  not  exceed  the 
server  vehicle’s  speed  at  any  time.  Were  this  not  true,  the  server  vehicle  would  need  to 
alter  its  operations  by  slowing  down  to  pennit  the  server  vehicle  to  rendezvous.  A  more 
general  implication  is  that  sensor  vehicle  dynamic  characteristics  must  not  exceed  those 
of  the  server  vehicle  to  a  degree  that  rendezvous  may  be  disrupted.  The  detailed  dynamic 
limits  would  be  dependent  on  the  rendezvous  communications  method.  An  example 
would  be  a  sensor  vehicle  whose  turn  rate  so  exceeds  the  server  vehicle’s  that  rendezvous 
communications  between  vehicles  is  significantly  disrupted.  A  directional  optical 
method  might  impose  stringent  limitations  on  vehicle  turn  rates  and  other  dynamics  to 
ensure  that  the  directional  sending  /  receiving  devices  stay  aligned  during  rendezvous. 
However  a  more  omni-directional  acoustic  method  might  only  require  that  vehicles 
remain  within  it’s  maximum  range  capability  during  maneuvers,  permitting  divergent 
turn  rates  and  courses  so  long  as  they  do  not  result  in  exceeding  this  maximum  range.  In 
summary,  we  assume  that  vehicle  dynamics  are  controlled  such  that  they  cannot  disrupt  a 
rendezvous  in  progress. 
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8.  Vehicles  Maintain  Ground  Track  and  Speed  Through  Water 

In  the  presence  of  currents,  AUVs  can  be  expected  to  be  set  away  from  their 
intended  track  over  ground.  The  usual  response  to  this  effect  is  for  the  AUV  to  adjust  its 
heading  and  assume  a  “crab  angle”  to  counter  the  effect  of  currents.  Ground  track  is 
maintained,  although  speed  over  ground  may  be  affected.  In  this  implementation,  the 
rendezvous  planning  process  assumes  that  vehicles  subject  to  currents  adjust  their  courses 
accordingly.  However,  they  are  assumed  to  maintain  their  pre-planned  speed  through  the 
water  while  doing  so,  making  no  adjustment  in  speed  for  the  effects  of  currents.  This  is 
reasonable  since  vehicles  will  frequently  operate  at  a  maximum  or  minimum  attainable 
speed  through  the  water,  in  which  case  no  increase  or  decrease  in  speed  may  be  possible. 

9.  Optimality 

Rendezvous  trajectories  are  to  satisfy  either  a  minimum  energy  or  minimum  time 
optimization  objective. 

10.  Robustness 

Software  must  be  tolerant  of  real-world  effects  such  as  navigation  inaccuracy, 
communications  drop-outs  or  garbles,  or  ocean  currents. 

D.  ROBUSTNESS  FEATURES 

The  following  features  were  incorporated  into  rendezvous  management  software. 

1.  Rendezvous  Queue  Management 

The  asynchronous  nature  of  the  network  results  in  random  arrival  of  rendezvous 
requests  from  sensor  vehicles.  Additionally,  a  request  from  one  vehicle  may  arrive  while 
the  server  vehicle  is  closing  or  engaged  in  rendezvous  with  another  sensor  vehicle. 
Requests  are  queued  for  action  in  order  of  arrival,  with  the  first  request  completed  in  its 
entirety  before  the  next  request  is  acted  upon.  Also,  since  rendezvous  requests  convey 
sensor  vehicle  navigation  data  which  may  change  significantly  while  the  request  is  in  the 
queue,  sensor  vehicles  may  send  subsequent  rendezvous  requests  containing  updated 
navigation  data.  The  queue  is  managed  such  that  the  updated  request  replaces  the 

previous  request  for  any  sensor  vehicle  in  the  queue,  rather  than  adding  it  to  the  queue  as 
a  new  rendezvous  request.  If  such  a  request  is  received  from  the  sensor  vehicle  that  the 
server  vehicle  is  enroute  to  rendezvous  with,  receipt  of  the  request  triggers  an  immediate 
replanning  of  the  rendezvous. 
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2.  Missed  Rendezvous  Logic 

Once  a  rendezvous  is  planned,  the  rendezvous  process  must  be  able  to  overcome  a 
failure  of  rendezvous  communications  at  the  rendezvous  point.  Action  must  be  taken  to 
correct  the  problem  and,  if  uncorrected,  the  rendezvous  must  be  tenninated  so  that  the 
server  vehicle  can  break  out  of  this  state  and  proceed  with  other  aspects  of  its  operation. 
This  situation  could  be  caused  by  a  failure  of  communications  equipment,  incorrect 
rendezvous  planning  by  the  server  vehicle,  or  by  inaccurate  navigation  or  equipment 
malfunction  for  either  vehicle.  In  such  instances,  the  server  vehicle  first  queries  the 
sensor  vehicle  to  report  its  present  navigation  data  so  that  another  rendezvous  can  be 
planned.  If  no  response  to  this  query  is  received,  the  server  vehicle  abandons  the 
rendezvous  and  deletes  the  rendezvous  request  from  the  queue. 

3.  Rendezvous  Request  Check  Sum 

One  possible  cause  of  the  above  missed  rendezvous  scenario  is  the  possibility  that 
garbled  navigation  data  contained  in  the  rendezvous  request  results  in  the  incorrect 
planning  of  a  rendezvous,  with  the  server  arriving  at  an  erroneous  rendezvous  point.  To 
prevent  this  occurrence,  rendezvous  requests  contain  check  sums  to  improve  the 
probability  of  correct  receipt  of  rendezvous  request  navigation  data. 

4.  Mission  Feasibility  Check 

To  guard  against  other  unforeseen  causes  of  incorrect  rendezvous  planning,  the 
final  results  of  the  rendezvous  mission  generated  by  the  mission  planning  process  is 
checked  for  feasibility  of  waypoint  positions.  A  navigational  envelope  is  defined  around 
the  area  of  operations  which  contains  all  expected  sensor  vehicle  positions  during  the 
operation.  If  any  of  the  waypoints  contained  in  the  rendezvous  mission  generated 
onboard  ARIES  fall  outside  of  this  envelope  the  mission  is  deemed  infeasible  and  is  not 
acted  upon  unless  a  subsequent  rendezvous  request  containing  corrected  sensor  vehicle 
position  data  is  received. 

5.  Currents 

Because  currents  can  significantly  affect  navigation  accuracy,  the  rendezvous 
planning  process  accepts  set  (direction)  and  drift  (magnitude)  of  currents  as  inputs  and 
accounts  for  their  effects  on  vehicle  speeds  and  headings  in  planning  rendezvous 
missions. 
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6.  Navigation  Accuracy 

Because  ARIES  fixes  its  position  by  surfacing  for  GPS  fixes,  it  can  only  fix  its 
position  periodically,  generally  once  every  few  minutes.  The  remained  of  the  time  it  uses 
speed  and  heading  sensors  to  dead  reckon  its  position.  Sensor  errors  lead  to  position 
errors  that  grow  over  time.  Additionally,  it  is  reasonable  to  expect  that  sensor  vehicles 
are  affected  similarly,  and  will  periodically  update  their  reported  positions.  To  account 
for  these  effects  and  update  the  rendezvous  solution,  rendezvous  missions  are 
periodically  replanned  while  in  progress. 

E.  BASELINE  ARIES  CHARACTERISTICS 

The  NPS  ARIES  vehicle  is  a  shallow-water  AUV  used  as  a  test-bed  to  explore 
new  concepts  for  autonomous  vehicles.  As  such,  its  hardware  and  software  are 
frequently  modified.  The  following  description  applies  to  its  “baseline”  or  normal 
configuration,  prior  to  modification  for  rendezvous  operations. 

1.  Hardware 

Key  components  are  shown  in  Fig.  21.  ARIES  is  powered  by  6  lead-acid  batteries 
which  provide  several  hours  worth  of  power.  Propulsion  is  provided  by  two  fixed  stern- 
mounted  thrusters  and  vehicle  attitude  is  controlled  by  two  bow  planes,  two  stem  planes 
and  two  top-mounted  rudders.  It  navigates  by  fusing  a  variety  of  navigation  sensors; 
including  compasses,  velocimeters,  gyros,  an  inertial  measurement  unit,  and  a  GPS 
receiver  which  provides  fix  infonnation  whenever  the  GPS  antenna  is  out  of  the  water 
and  exposed  to  the  GPS  satellite  constellation.  The  present  sensor  configuration  consists 
of  a  video  camera  and  supporting  storage,  processing,  and  transmission  equipment, 
although  various  sonar  systems  have  also  been  carried.  Because  of  its  design  as  a 
communications  node,  ARIES  carries  both  radio  and  acoustic  communications 
equipment.  For  the  implementation  of  AUV  rendezvous  the  key  piece  of 
communications  equipment  was  the  Benthos  acoustic  modem,  which  has  been  used  for 
previous  communications  research  (Marr,  2002)  and  which  enables  communications 
between  submerged  vehicles.  Its  capabilities  were  adequate  for  command  and  control 
communications  such  as  sending  and  receiving  rendezvous  requests  and  for  reporting 
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Figure  21.  ARIES  Vehicle  Diagram  (After:  Marco,  2001) 


52 


vehicle  status.  No  hardware  modification,  other  than  addition  of  the  electrical  current 
sensor  used  to  measure  ARIES’  power  characteristic  function,  was  necessary. 

ARIES’  operation  is  controlled  by  a  dual  processor  computer.  Each  processor 
consists  of  a  Pentium  166MHz  CPU  on  an  EBX  motherboard,  each  hosting  various  PC- 
104  input/output  cards.  Both  processors  run  the  QNX  4.23a  real-time  operating  system. 
Communications  between  processors  and  to  other  computers  is  via  a  10Base2  Ethernet 
connection.  An  additional  connection  to  the  processor  designated  QNXE  is  provided  via 
FreeWave  radio  modem.  This  connection  is  used  during  ARIES  operations  when  ARIES 
is  not  physically  connected  to  an  Ethernet  cable,  and  permits  command  and  control  of  the 
vehicle  while  it  is  on  the  surface. 

2.  Software 

The  baseline  ARIES  software  architecture  is  as  shown  in  Fig.  22.  The  primary 
function  of  the  processor  designated  QNXT  is  navigation.  It  hosts  several  processes, 
most  of  which  process  data  from  navigation  hardware.  Associated  with  each  process  are 
shared  memory  blocks  where  processed  data  is  written  for  reading  by  the  Nav  process. 
The  Nav  process  uses  an  extended  Kalman  filter  to  fuse  sensor  data  into  accurate 
navigation  data.  QNXT  also  hosts  processes  for  overlaying  navigation  data  onto  video 
images  (Bob  II),  for  digitizing  analog  signals  from  navigation  equipment  and  other 
vehicle  systems  (Analog),  and  for  transmitting  navigation  data  to  QNXE  (QtS). 

QNXE  controls  vehicle  mission  execution.  It  receives  the  navigation  data 
supplied  by  QNXT  via  the  network  process  QeR  and,  using  various  sliding  mode 
autopilots,  sends  commands  to  ARIES’  six  control  surfaces  to  maintain  course  and  depth. 
The  mission  is  described  in  the  mission  script  file,  which  could  contain  a  sequence  of 
low-level  commands  such  as  thruster  speeds,  control  surface  angles,  headings,  depths,  or 
altitudes  to  be  executed.  However,  usual  ARIES  missions  are  described  at  a  higher  level. 
Rather  than  specifying  the  low-level  details  of  the  mission,  the  script  file  typically  calls 
for  a  “waypoint  control”  mission.  In  this  case,  a  second  file  which  describes  the  mission 
as  a  series  of  navigation  waypoints  is  read  into  the  Exec  process  at  the  start  of  the 
mission.  Each  line  of  this  file  specifies  the  position  of  the  next  waypoint,  as  well  as  the 
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QNXE  1  QNXT 


Figure  22.  ARIES  Baseline  Computer  Software  Architecture,  Showing  Processors,  Network 
Connections,  Processes,  Shared  Memory  (SM)  Structures,  and  Mission  Definition 
Files.  Boxed  Region  in  QNXE  Was  Later  Modified  for  Rendezvous  as  shown  in 

Fig.  24  (After:  Marco,  2001) 


speed,  depth  or  altitude,  time  limit  for  arriving  at  the  next  waypoint,  and  how  closely  to 
approach  the  waypoint  before  activating  the  next  waypoint.  The  details  of  the  ARIES 
waypoint  file  are  shown  in  Fig.  23. 
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Each  row  defines  a  single  way  point.  Columns  1-11  contain: 

Column  Description 

1  Way  point  X  position  (meters). 

2  Way  point  Y  position  (meters). 

3  Left  screw  speed  command  (volts). 

4  Right  screw  speed  command  (volts). 

5  Control  mode  flag,  0  =  Depth  control,  1  =  Altitude  control. 

6  Altitude  command  (meters,  if  applicable). 

7  Depth  command  (meters,  if  applicable). 

8  Perform  GPS  popup  on  this  track,  1  =  Yes,  0  =  No. 

9  Duration  of  GPS  popup  (sec). 

10  Watch  radius  (meters) 

1 1  Way  point  timeout  -  mission  aborts  if  ARIES  has  not  reached  the  watch  radius  of  the  waypoint 
after  heading  for  this  waypoint  for  this  amount  of  time  (sec) 


Figure  23.  Structure  of  ARIES  Way  Point  File  (After:  Marco,  2001) 


The  nonnal  method  to  log  in  to  ARIES’  computers  is  via  10Base2  ethemet 
connection  to  the  QNXE/QNXT  network.  The  operator  uses  network  utilities  such  as 
telnet  and  ftp  to  control  computer  operations;  retrieve,  edit,  and  store  computer  fdes; 
compile  the  C  code  in  which  ARIES  is  programmed;  and  start  and  stop  processes  and 
missions.  QNXE  also  provides  two  methods  of  communications  with  ARIES  when  it  is 
physically  disconnected  from  a  computer  network,  as  is  the  case  during  underway  ARIES 
operations.  A  FreeWave  radio  modem  connection  via  a  serial  port  pennits  an  operator  to 
take  control  and  issue  commands  to  QNXE  when  the  FreeWave  antenna  is  above  the 
surface  of  the  water  during  an  operation.  Additionally,  ARIES’  acoustic  modem  is 
controlled  by  a  process  (fm)  hosted  by  QNXE.  The  modem  does  not  provide  direct 
control  of  the  QNXE  processor,  as  does  login  over  the  FreeWave  or  10Base2  Ethemet 

connection,  but  it  does  accept  a  limited  set  of  commands  defined  in  and  recognized  by  the 
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fm  and  Exec  processes.  Such  commands,  if  successfully  parsed  by  the  modem  process, 
are  written  to  modem  shared  memory  where  the  Exec  process  reads  and  executes  the 
command.  Additionally,  if  the  modem  process  successfully  parses  and  passes  on  to  the 
Exec  process  a  pre-defined  query  for  data,  the  processes  obtain  and  write  the  requested 
data  to  the  modem  for  transmission. 

F.  HARDWARE  MODIFICATIONS  TO  ENABLE  RENDEZVOUS 

Because  ARIES  was  designed  to  serve  as  a  communications  node,  little  hardware 
modification  was  necessary.  The  only  change  was  installation  of  the  electric  current 
sensor  which  was  used  to  determine  the  vehicle’s  power  characteristics.  After  measuring 
the  necessary  power  data,  this  sensor  remained  in  place  as  a  development  tool  for  future 
ARIES  modifications.  It  is  not  necessary  for  actual  rendezvous  operations  as 
implemented  here. 

G.  SUMMARY  OF  NECESSARY  SOFTWARE  MODIFICATIONS 

The  basic  navigational  nature  of  QNXT  processes  required  no  modification. 
However,  because  of  the  command  and  control  nature  of  QNXE  processes,  extensive 
modification  was  required  in  QNXE  software. 

1.  Dynamic,  Autonomous  Mission  Planning  Process 

As  is  the  case  with  most  AUVs,  an  ARIES  mission  is  written  and  loaded  into  the 
vehicle  prior  to  starting  the  mission.  At  the  start  of  the  mission  ARIES  parses  the 
mission  script  file,  which  normally  directs  it  to  read  the  contents  of  the  way  point  file  into 
memory.  The  mission  then  consists  of  ARIES  driving  to  each  way  point  in  a  pre¬ 
determined  sequence  and  manner.  This  relatively  static  mission  definition  is  unsuitable 
for  the  rendezvous  operations  in  that  it  does  not  permit  ARIES  to  respond  to  rendezvous 
requests.  To  respond  to  a  rendezvous  request,  ARIES  operations  must  change  once 
execution  has  begun.  Beginning  with  a  “loiter  phase”,  the  operation  must  progress  to  a 
“closing  phase”  in  response  to  a  feasible  rendezvous  request.  During  the  closing  phase 
ARIES  closes  the  position  of  the  sensor  or  target  vehicle.  At  the  rendezvous  point 
ARIES  must  transition  to  a  “rendezvous  phase”,  during  which  it  remains  in  close 
proximity  of  the  target  vehicle  and  conducts  rendezvous  communications.  Finally,  upon 
completion  of  rendezvous  communications,  ARIES  must  return  to  its  loiter  phase.  These 

transitions,  which  involve  timing  and  positioning  which  cannot  be  known  a  priori,  require 
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dynamic,  autonomous,  on-board  planning  of  the  new  mission.  To  accomplish  this  a  new 
rendezvous  planning  process,  named  RPlan,  was  written  to  run  concurrently  and  interact 
with  a  version  of  the  Exec  process  modified  for  rendezvous  to  allow  activation  of  new 
missions  during  an  ARIES  rendezvous  operation.  This  modified  process  is  named 
RExec. 

For  baseline  ARIES  operations,  involving  the  execution  of  a  mission  defined  by  a 
single  waypoint  file,  the  tenn  “mission”  refers  to  both  the  entirety  of  ARIES’  behavior 
during  a  single  deployment  as  well  as  the  contents  of  a  single  waypoint  file.  To  avoid 
confusion  in  rendezvous  ARIES  terminology,  where  multiple  “missions”  may  be 
executed  during  a  single  deployment,  the  term  “mission”  will  refer  to  the  contents  of  a 
single  waypoint  file.  The  term  “operation”  will  refer  to  an  ARIES  deployment,  during 
while  several  “missions”  are  expected  to  be  executed. 

2.  Additional  Layer  of  Control 

The  sequence  of  events  involved  in  responding  to  a  rendezvous  request  must  be 
controlled  by  a  higher  level  of  logic  than  that  of  the  base  line  ARIES  or  most  other 
current  AUVs.  Whereas  the  typical  AUV  mission  follows  a  sequence  of  waypoints  or 
commands,  rendezvous  operations  involve  interpreting  inter-vehicle  communications, 
dynamic  mission  planning,  error  checking,  multiple  mission  activation,  and  measures  to 
provide  robustness  in  the  event  of  plausible  problems.  Management  of  such  operations 
requires  an  additional  layer  of  supervisory  logic.  In  this  implementation,  a  finite  state 
machine  was  incorporated  into  the  Exec  process  to  monitor  operation  events  and  to  shift 
ARIES  mode  of  control  of  in  response. 

3.  Mission  Activation 

Once  written,  the  planned  mission  must  be  activated.  In  other  words,  its  way 
points  and  other  data  must  be  read  into  Exec  memory  and  the  vehicle  mission  set  to 
execute  it.  The  baseline  ARIES  software  performed  this  step  once,  at  the  beginning  of  its 
mission,  with  the  mission  consisting  of  proceeding  to  each  way  point  in  succession. 
Upon  arriving  at  the  final  waypoint,  the  mission  was  terminated.  For  rendezvous, 
mission  activation  must  take  place  mid-operation,  whenever  required  by  initiation  or 
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completion  of  rendezvous.  To  accomplish  this,  Exec  was  modified  to  allow  mission 
activation  whenever  required.  Additionally,  any  of  several  way  point  files  could  be 
activated. 

4.  Queue  Management 

The  asynchronous  nature  of  the  vehicle  network  required  a  queue  in  which  to 
store  incoming  rendezvous  requests.  Additionally,  typical  queue  management  functions 
were  necessary  to  perform  such  actions  as  testing  for  the  presence  of  a  request  in  the 
queue,  clearing  the  top  request  from  the  queue  once  action  is  complete,  or  writing  a  new 
request  to  the  bottom  of  the  queue.  Because  queued  rendezvous  requests  contained 
sensor  vehicle  navigation  data,  which  could  be  updated  by  the  sensor  vehicle  while  the 
request  remained  queued,  queue  management  in  this  implementation  also  need  to 
distinguish  between  initial  and  subsequent  rendezvous  requests  from  the  same  sensor 
vehicle.  In  the  former  case,  the  request  is  written  to  the  queue.  In  the  latter,  the  initial 
request  retains  its  position  in  the  queue,  with  the  navigation  data  contained  in  the  request 
being  overwritten  by  the  updated  data  contained  in  the  subsequent  request. 

5.  Shared  Memory 

Shared  memory  is  a  method  used  by  the  QNX  operating  system  to  make  data 
available  between  cooperating  processes.  Shared  memory  structures  are  initialized  at 
boot-up,  and  may  be  accessed  by  multiple  processes  for  reading  or  writing  data.  Before  a 
process  writes  data  to  or  reads  data  from  a  shared  memory  structure,  it  sets  a  semaphore 
to  prevent  ah  other  processes  from  accessing  shared  memory  until  the  operation  is 
complete.  On  completion  it  clears  the  semaphore,  allowing  access  to  the  next  process 
attempting  to  read  or  write  to  shared  memory.  Shared  memory  was  already  used 
extensively  in  ARIES  prior  to  modification  for  rendezvous.  Implementation  of  the 
rendezvous  behavior  resulted  in  addition  of  new  variables  to  existing  structures,  as  well 
as  addition  of  a  new  structure  to  accompany  the  new  mission  planning  process. 

6.  Modem  Upgrade 

As  the  conduit  for  rendezvous  command-and-control  communications,  the 

modem  process  required  modification.  Some  modification  involved  adapting  its 

vocabulary  to  recognize  messages  required  by  the  rendezvous  process.  However,  the 

process  was  also  rewritten  to  allow  ARIES  to  initiate  modem  communications,  something 
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ARIES  Main  Control  Loop  (8  Hz) 


Figure  24.  QNXE  Software  Modifications  to  Implement  Rendezvous.  Baseline  ARIES 

Features  are  Light.  Proxy  Trigger  and  Dark  Features  were  Added  for  Rendezvous 
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it  had  not  done  before.  In  the  past,  ARIES  modem  transmissions  had  been  only  in 
response  to  modem  queries  from  another  modem. 

These  software  modifications  are  described  in  detail  in  the  following  sections. 
Figure  24  provides  an  overview  of  these  modifications. 

H.  MISSION  PLANNING  PROCESS 

1.  Efficient  Use  of  Computer  Resources 

Adding  a  new  process  to  the  QNXE  processor  and  its  existing  processes, 
especially  one  which  potentially  would  involve  extensive  mathematical  computations  as 
well  as  file  input  and  output,  led  to  an  early  decision  make  the  process  as  computationally 
efficient  as  possible.  Were  the  addition  of  the  planning  process  to  consume  the 
remainder  of  QNXE’s  available  resources,  vital  vehicle  control  functions  in  the  Exec 
process  such  as  autopilots  could  be  disrupted.  The  following  measures  were  taken  to 
minimize  the  effect  of  the  new  planning  process  on  existing  QNXE  processes: 

-  The  planning  process  was  written  as  a  separate  process,  rather  than  a  function  to 
be  called  by  Exec.  Although  an  analysis  of  QNXE  loading  indicated  that  a  substantial 
amount  of  unused  resources  were  available  for  a  planning  process,  the  computational 
requirements  of  such  a  process  would  be  unknown  until  it  was  written.  Writing  the 
planning  process  as  a  separate  process  allowed  the  possibility  of  running  it  as  a  lower 
priority  than  other  QNXE  processes,  a  feature  of  the  QNX  4.23a  operating  system.  As  a 
lower  priority  process,  the  planning  process  would  use  whatever  QNXE  computer 
resources  were  available  once  other  processes  were  serviced.  This  is  pennissible  since 
the  planning  of  the  rendezvous  mission  is  less  time  critical  than  vehicle  control  functions. 

-  The  mission  planning  process  was  written  such  that  it  remained  “receive 
blocked”  until  it  was  necessary  to  plan  a  mission.  In  this  state,  an  inter-process  control 
feature  of  the  QNX  4.23a  operating  system,  execution  of  the  planning  process  is  halted 
until  it  receives  a  signal  from  the  RExec  process.  RExec  sends  this  signal  by  triggering  a 
QNX  proxy  message,  which  unblocks  and  starts  the  planning  process. 
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-  Wherever  possible,  planning  calculations  are  performed  prior  to  receipt  of  a 
rendezvous  request  to  minimize  calculations  required  during  rendezvous  request 
processing.  Examples  include  calculating  distances  and  courses  between  mission 
waypoints. 

Testing  of  the  completed  mission  planning  process  showed  that  QNXE  was 
capable  of  hosting  the  planning  and  existing  QNXE  processes  with  all  processes  running 
at  the  same  priority. 

2.  Data  Required  for  Mission  Planning 

A  variety  of  data  is  required  to  plan  the  rendezvous  between  the  ARIES  and  target 
vehicle;  including  ARIES  vehicle  dynamics,  ARIES  state  infonnation,  target  vehicle  state 
information,  magnitude  and  direction  of  currents,  and  target  vehicle  mission  parameters. 
This  data  can  be  divided  into  two  categories:  data  onboard  ARIES  prior  to  the  start  of 
rendezvous  mission  planning,  and  data  not  onboard  which  must  be  included  in  the 
rendezvous  request. 

An  ARIES  vehicle  dynamics  model  can  be  written  into  the  planning  process. 
Also,  ARIES  estimates  its  own  state,  and  that  information  is  onboard  at  all  times. 
Additionally,  assuming  that  ARIES  has  the  capability  to  measure  and  estimate  currents  in 
the  area  of  operations,  so  that  data  is  onboard  as  well.  It  may  be  obtained  as  the 
difference  between  velocity  over  ground  and  velocity  through  the  water,  both  of  which 
are  measured  by  the  Acoustic  Doppler  Current  Profiler  (ADCP). 

This  leaves  only  target  vehicle  state  infonnation,  some  of  which  is  assumed  to  be 
known  a  priori.  As  previously  discussed,  aspects  of  the  target’s  mission  that  are  not 
expected  to  change  during  the  operation  are  loaded  onto  ARIES  prior  to  the  start  of  the 
operation.  In  this  implementation  this  infonnation  was  a  sequential  list  of  each  target 
vehicle’s  waypoints.  Three  elements  described  each  waypoint:  X  coordinate  (meters),  Y 
coordinate  (meters),  and  vehicle  forward  speed  through  the  water  u  while  closing  each 
waypoint  (meters  per  second)  .  Describing  the  target  vehicle’s  mission  in  this  manner 
reduces  the  set  of  possible  vehicle  positions  to  a  single  segmented  linear  feature. 

The  only  remaining  data  required  to  plan  the  rendezvous  is  the  target  vehicle’s 
position  along  this  path.  This  information  generally  will  not  be  known  to  the  server 
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vehicle  unless  the  target  vehicle  is  additionally  constrained  to  maintain  its  progress  along 
track  in  accordance  with  a  pre-detennined  time  table,  an  overly  restrictive  requirement 
which  would  increase  the  complexity  of  target  vehicle  design  and  not  allow  for 
unforeseen  disturbances  to  target  vehicle  progress.  A  simple  and  accurate  way  to  locate 
a  vehicle  constrained  to  move  along  a  path  is  to  describe  its  location  as  its  progress  along 
the  path.  Progress  is  expressed  as  the  present  path  segment  being  completed  and  the 
fraction  of  that  segment  complete.  For  this  scheme  a  progress  value  of  0  represents  the 
vehicle  located  at  the  start  of  a  segment  and  1  represents  the  vehicle  located  at  the  finish. 
Target  vehicle  progress  is  included  in  the  rendezvous  request  as  a  method  of  locating  the 
target  vehicle,  the  remaining  information  required  to  plan  the  rendezvous  is  available 
onboard  ARIES. 

3.  Elements  of  a  Rendezvous  Request 

The  rendezvous  request  consists  of  the  following  elements.  All  are  integer  values 
that  are  transmitted  via  acoustic  modem  to  ARIES. 

a.  Sender  Identity 

Because  multiple  target  vehicles  may  be  involved  in  an  operation,  this 
element  identities  which  vehicle  sent  the  request. 

b.  Present  Track  Segment 

This  identifies  which  segment  of  its  mission  the  target  vehicle  is  presently 
completing,  which  is  also  the  number  of  the  way  point  at  the  end  of  the  segment.  As  a 
result,  way  point  “0”  identities  the  starting  point  of  the  target’s  track  and  “1”  is  both  the 
first  segment  of  the  target’s  track  and  the  waypoint  at  the  end  of  the  track. 

c.  Progress  Along  Present  Track  Segment 

This  is  a  three-digit  integer  describing  fraction  of  present  track  segment 
complete,  expressed  in  thousandths. 

d.  Time  Stamp 

Target  vehicle  position  must  be  accompanied  by  the  time  the  position  was 
detennined  so  that  ARIES  can  correct  the  reported  target  vehicle  position  for  time  delays 
in  transmitting  and  receiving  the  rendezvous  request.  Modem  processing  and  sound 
propagation  delays  typically  introduce  several  seconds  of  delay  from  transmission  to 

reception  and  processing.  This  integer  conveys  the  time  for  which  rendezvous  request 
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target  vehicle  state  data  was  valid,  in  seconds  since  start  of  the  operation.  Note  that  this 
scheme  requires  synchronized  clocks  on  ARIES  and  target  vehicles. 

e.  Check  Sum 

Because  an  ARIES  rendezvous  mission  is  based  on  the  information 
contained  in  a  rendezvous  request,  because  of  the  amount  of  data  contained  in  the 
rendezvous  request,  and  because  of  the  likelihood  that  the  rendezvous  request  may  arrive 
garbled  after  long-range  transmission  between  widely  separated  vehicles,  a  check  sum  is 
included  in  the  rendezvous  request.  It  is  a  simple  sum  of  the  four  integers  that  precede  it 
in  the  request.  The  check  sum  serves  a  second  purpose  in  this  demonstration  of 
rendezvous  behavior,  where  it  is  desirable  to  specify  the  optimization  objective  in  the 
rendezvous  request.  To  specify  a  time-optimal  rendezvous  the  check  sum  is  given  a 
positive  sign,  while  a  negative  check  sum  signals  an  energy-optimal  rendezvous.  For 
rendezvous  operations  outside  of  this  demonstration,  the  particulars  of  the  operation 
would  determine  whether  time-optimal  or  energy-optimal  rendezvous  is  desirable.  In 
such  cases  this  parameter  would  be  set  in  ARIES  prior  to  the  operation,  and  would  not  be 
a  necessary  element  of  the  rendezvous  request. 

4.  Pre-Processing  Target  Data 

The  following  calculations,  which  are  perfonned  on  target  data  prior  to  the  receipt 
of  a  rendezvous  request,  produce  results  that  either  will  not  change  over  the  course  of  an 
operation  or  change  slowly  enough  that  they  need  not  be  repeated  for  each  rendezvous 
request.  This  data  is  stored  in  a  series  of  two-dimensional  data  arrays,  with  each  row 
corresponding  to  a  waypoint  number  and  each  column  corresponding  to  a  target  vehicle 
number.  Note  that  in  the  C  programming  language  used  in  ARIES,  the  first  element  of  an 
array  is  numbered  “0”.  Using  this  convention,  the  first  waypoint  of  a  mission  is  the  “0th” 
way  point,  and  the  first  row  or  column  of  a  two-dimension  array  is  the  “0th”  row  or 
column. 

a.  Compute  Segment  Lengths 

The  Euclidean  distance  between  each  successive  way  point  in  a  target’s 
mission  is  computed  and  stored  in  the  array  SegLen.  Since  the  first  segment  of  the 
target’s  mission  is  the  segment  from  waypoint  0  (first  waypoint)  to  waypoint  1  (second 

way  point),  the  first  row  of  the  SegLen  array  to  contain  computed  segment  lengths  is  row 
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1.  Row  0  contains  zeros,  as  there  are  only  n-1  distances  to  compute  between  n  way 
points.  The  first  row  of  each  of  the  following  data  arrays  are  also  zeroes. 

b.  Compute  Segment  Courses  Over  Ground 

The  course  over  ground  y/  for  each  segment  is  computed  as: 

V/g=atan2(AT/^)  (5.!) 

or,  the  arctangent  of  the  ratio  of  change  in  Y  coordinate  and  X  coordinate  between  two 
successive  way  points  expressed  as  a  value  between  -pi  and  pi.  These  are  stored  in  the 
array  SegPsi 

c.  Compute  Target  Vehicle  Speed  Over  Ground  and  Heading  for 
Each  Segment 

In  the  absence  of  currents  and  other  perturbations  vehicle  heading  equals 
course  over  ground.  However,  rendezvous  operations  are  assumed  to  take  place  in  the 
presence  of  currents,  and  their  effect  is  accounted  for.  Because  the  direction  and 
magnitude  of  local  currents  vary  slowly,  their  effects  can  be  computed  periodically  on  an 
appropriate  time  scale  and  considered  constant  between  such  updates.  Doing  so  reduces 
the  computations  required  in  response  to  a  rendezvous  request.  The  target  vehicle 
velocity  over  ground  vector  is  the  vector  sum  of  velocity  through  the  water  and  current 
velocity.  Given  the  previous  assumption  that  the  target  vehicle  maintains  its  ground 
track,  the  known  quantities  of  course  over  ground,  current  magnitude  and  direction,  and 
speed  through  the  water  can  be  used  to  solve  for  vehicle  heading  and  speed  over  ground. 
These  quantities  are  stored  in  the  two-dimensional  arrays  Psi  and  U_g,  and  are  updated 
whenever  magnitude  and  direction  of  currents  are  updated. 

5.  Planning  Time-Optimal  Rendezvous 

The  following  is  the  sequence  of  events  for  a  time-optimal  rendezvous  request, 
assuming  that  the  received  request  is  properly  formatted  and  the  planning  process  passes 
all  checks. 

a.  Validating  Rendezvous  Request  Format 

Upon  receipt  by  the  acoustic  modem,  the  header  of  any  incoming  message 
is  compared  against  established  message  header  formats  to  establish  the  type  of  message 
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received  and  to  handle  it  accordingly.  Once  the  incoming  message  is  classified  a 
rendezvous  request  message,  the  message  is  parsed  into  individual  data  elements  which 
are  written  into  corresponding  modem  shared  memory  variables.  A  flag  in  modem 
shared  memory  is  also  set  to  signal  arrival  of  a  recognized  message  type  to  the  RExec 
process,  which  reads  the  message  data  from  modem  shared  memory  into  the  appropriate 
RExec  process  variables. 

Data  received  in  the  RExec  process  is  checked  against  its  check  sum  and 
written  into  the  RExec  rendezvous  queue.  At  the  appropriate  time,  as  determined  by  the 
finite  state  machine,  the  request  is  retrieved  from  the  rendezvous  queue  and  computations 
begin  which  will  result  in  a  complete  rendezvous  mission  waypoint  file. 

b.  Determining  Future  Target  Vehicle  Positions  and  Synchronizing 
Data 

To  plan  the  rendezvous  the  planning  process  must  adjust  target  position 
reported  in  the  rendezvous  request  for  delays  in  receiving  the  request  and  must  project 
target  position  into  the  future.  The  method  of  accomplishing  this  begins  with 
determining  the  expected  time  of  arrival  at  each  waypoint,  beginning  with  the  last  way 
point  reached  by  the  target  vehicle.  For  target  vehicle  i  on  segment  j,  this  is  way  point  j- 
1 .  The  time  t  that  the  target  vehicle  arrived  at  this  previous  way  point  is  computed  as: 


r,_n  .  {r'rog  y^egLenu  ,1 }) 

L  J  -I  stamp  y  t  r  •  < 

U_g[j,i] 


wherc  K,amP  is 


the  time  stamp  contained  in  the  rendezvous  request,  Prog  is  the  target’s 

fractional  progress  down  the  present  segment  ([j,i])  expressed  as  a  number  between  0  and 
1 ,  and  t  is  clock  time  of  the  operation  at  the  time  of  computation,  which  was  initialized 


at  zero  for  all  vehicles  at  the  start  of  the  operation.  In  general,  t[j-l]  has  a  negative  value. 
This  calculation  removes  the  effects  of  delays  in  transmitting  and  processing  the 
rendezvous  request,  thereby  synchronizing  the  target’s  state  data  to  ARIES’  data  .  Also 
note  that  times  produced  by  this  calculation  define  the  time  of  computation  as  t=0,  so  that 
all  times  are  conveniently  referenced  to  the  time  of  computation.  The  target  arrival  times 
at  way  point  [j]  and  subsequent  way  points  are  computed  sequentially  as: 
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t[j]=t[j- 1]+ 
t[j  + 1]  =  t[j]  + 


Seglen[j,i ] 
U_g[j,i ] 
Seglen[j  + 1,/] 

^.gt/'  +  U] 


(5.3) 


Target  future  position  and  arrival  time  at  each  way  point  is  now  established.  Using  these 
discrete  future  positions  and  times  as  a  basis,  and  knowing  speed  over  ground  for  each 
segment,  future  target  position  can  be  determined  for  any  future  time,  or  target  time  of 
arrival  can  be  determined  for  any  future  position  along  its  track. 

c.  Locating  the  Time-Optimal  Rendezvous  Point 
The  next  step  in  planning  the  time-optimal  rendezvous  is  to  identify  the 
time-optimal  rendezvous  point,  or,  the  earliest  time  that  ARIES  can  rendezvous  with  the 
target  vehicle.  The  method  for  finding  this  point  is  based  on  the  concept  of  reachable 
states,  as  discussed  in  Ch.  III.  Locating  this  time-optimal  rendezvous  point  proceeds  by 
examining  each  future  target  vehicle  way  point  and  determining  whether  or  not  it  lies 
within  ARIES  set  of  reachable  states.  Because  ARIES  dynamics  envelope  is  assumed  to 
always  include  those  of  the  target  vehicle,  the  problem  timeline  is  divided  into  two 
periods.  During  an  early  period  rendezvous  is  not  feasible,  usually  because  ARIES’ 
maximum  speed  does  not  allow  it  to  reach  the  target  vehicle  by  that  time.  During  a  later 
period  rendezvous  is  always  feasible.  The  boundary  between  these  two  periods  is  the 
earliest  feasible  rendezvous  time,  and  only  one  such  boundary  exists.  It  is  located  by 
sequentially  evaluating  each  of  the  target  vehicle’s  future  waypoints  and  detennining 
whether  ARIES  can  reach  that  point  at  the  time  the  target  is  due  to  arrive  there,  on  the 
same  course  and  speed  as  the  target,  i.e.,  by  determining  whether  rendezvous  is  possible 
at  that  point.  The  earliest  way  point  for  which  rendezvous  is  feasible  lies  at  the  end  of  the 
segment  that  contains  the  time  optimal  rendezvous  point,  for  the  beginning  point  of  that 
segment  was  a  non-feasible  point  and  therefore  these  two  points  bound  the  time-optimal 
rendezvous  point. 
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Rendezvous  feasibility  for  a  given  point  on  the  target  vehicle’s  track 
consists  of  determining  whether  there  is  sufficient  time  for  ARIES  to  transit  to  the  point 
and  match  target  vehicle  course  and  speed,  assuming  ARIES  transits  at  maximum  speed 
and  accounting  for  the  time  and  distance  required  for  ARIES  to  accelerate,  turn  as 
necessary,  and  decelerate  to  target  speed. 

Such  calculations  require  models  of  ARIES  acceleration  and  deceleration 
(surge)  and  turn  dynamics.  An  easily  implementable  and  sufficiently  accurate  surge 
dynamics  model  suitable  for  this  application  was  a  first  order  linearly-damped  model  of 
the  form: 

u(t)  =  ui  +  (uf-ui)e~Al  (5.4) 

where  it  and  u  f  are  initial  and  final  forward  speeds,  respectively.  ARIES  operational 

data  showed  the  value  of X  to  be  approximately  0.2,  yielding  a  five  second  time  constant. 
This  yields  a  speed  model  which  can  be  easily  integrated  to  compute  the  vehicle  path 
length  L  required  for  the  speed  change: 

Z(0  =  «/-^yL(  {-e  )  (5.5) 

The  exponential  form  of  the  above  equation  results  in  infinitely  long  path 
lengths  since  this  representation  for  speed  never  exactly  reaches  steady  state.  To  prevent 
this  and  to  keep  the  result  practical,  the  planning  process  considers  the  speed  transient 
complete  once  ARIES  speed  is  within  0.1  meters  per  second  of  its  steady  state  value. 
The  model’s  fidelity  with  an  actual  ARIES  speed  transient  is  shown  in  Fig.  25. 

Similarly,  a  simple  model  of  ARIES  turn  dynamics  was  necessary.  The 
common  empirically  determined  turn  parameters  for  marine  vehicles,  advance  and 
transfer,  were  used  in  this  application  and  are  shown  in  Fig.  26.  Advance  is  the  distance 
along  the  initial  track  that  the  vehicle  travels  during  the  turn,  and  transfer  is  the  cross¬ 
track  distance  during  the  turn.  These  parameters  describe  the  physical  dimensions  of  a 
vehicle’s  turn,  allowing  the  rendezvous  planning  process  to  model  turns  when  optimizing 
ARIES’  trajectory  in  a  rendezvous  mission. 
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U  (meters/second) 


Figure  25.  Comparison  of  ARIES  Speed  Transient  and  First-Order  Model 


Figure  26. 


Advance  and  Transfer 
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During  a  series  of  experiments  these  parameters  and  total  ARIES  turn  path 
length  were  measured,  and  models  fitted  to  the  data.  Path  length,  when  combined  with 
ARIES  speed,  determines  the  time  to  complete  the  turn.  A  cubic  polynomial  was  fit  to 
each  data  set: 

Advance  =  3.178(A^)3  -21.20(A^)2  +  36.83(A^)  (5.6) 

Transfer  =  -0.3837(A^)3  +  0.6694(A^)2  +9.362(A^)  (5.7) 

PathLength  =  3.345(A^)3  -  17.67(A^)2  +  37.0 1( A ^)  (5.8) 

These  functions  are  shown  in  Fig  27. 


Figure  27.  ARIES  Advance,  Transfer,  and  Path  Length  Versus  Course  Change 

Using  the  above  models,  along  with  information  on  set  and  drift  due  to 
currents,  the  time  and  change  in  position  required  for  each  ARIES  turn  is  computed  by 
the  planning  process  RPlan,  as  shown  in  Fig.  28. 
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a.  b. 

Figure  28.  Calculating  Effects  of  Course/Speed  Changes  With  Currents.  Large  Course 
Change  (a).  Small  Course  Change  With  Speed  Change  Continuing  After  Course 

Change  (b) 

As  discussed  in  previous  chapters,  these  turns  comprise  the  beginning 
and  end  of  ARIES’  closure  trajectory  for  rendezvous.  The  remaining  portion  of  the 
trajectory  is  a  straight,  steady-course,  steady-speed  segment  between  the  two  turns.  It 
covers  the  period  from  the  end  of  the  initial  course  and  speed  change  to  the  beginning  of 
the  final  course  and  speed  change.  Hence,  the  ARIES  trajectory  is  computed  as  three 
consecutive  and  separate  segments  tied  together  by  boundary  conditions  on  course, 
speed,  and  position  at  four  key  points.  Starting  at  ARIES’  initial  position  with 

initial  course  y/i  and  initial  speed  u, ;  point  1  (Aj ,  Tj )  is  the  end  of  the  initial  course  / 

speed  change  maneuver  and  the  start  of  the  straight  portion  of  the  trajectory  where 

ARIES  course  and  speed  are  i//!  and  ux  respectively.  Point  2  (X2,Y2)  is  the  end  of  the 

straight  portion  of  the  trajectory  and  the  start  of  the  final  course  /  speed  change  maneuver. 
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Note  that  i//2  =  i//,  and  u2  =  ul.  Point  3  (X3,Y3)  is  the  rendezvous  point.  At  this  final  point 

ARIES  position,  course,  and  speed  match  those  of  the  target  vehicle.  The  ARIES 
rendezvous  trajectory  is  shown  in  Fig. 29. 

Target 


Figure  29.  ARIES  Rendezvous  Trajectory 

The  process  of  planning  ARIES’  speed  changes  is  fairly  straightforward. 
The  initial  speed  change  takes  ARIES  from  its  initial  speed,  uj ,  to  the  speed  during  the 

straight  portion  of  closure, i\.  Recall  that  for  minimum  time  rendezvous  «,  is  ARIES’ 
maximum  attainable  speed. 

For  the  sake  of  simplifying  ARIES  mission  planning,  both  ARIES’  final 
turn  and  final  deceleration  begin  at  point  2.  This  is  a  deviation  from  the  results  of  the 
previous  chapters,  which  in  general  did  not  require  simultaneous  final  course  and  speed 
changes.  This  simplification  avoids  such  complexities  as  planning  a  way  point  during  the 
final  turn  to  begin  deceleration,  without  significantly  altering  the  optimization  of  the 
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rendezvous  trajectory.  This  does  not  occur  during  the  initial  turn  since  course  and  speed 
changes  begin  simultaneously  at  the  beginning  of  this  turn.  The  result  of  this  simplified 
planning  of  the  final  turn  is  that  ARIES  either  steadies  on  final  course  while  decelerating, 
or  reaches  final  speed  while  completing  the  turn,  neither  of  which  lead  to  significant  sub- 
optimization. 

The  process  of  determining  whether  a  target  vehicle  future  waypoint  is 
feasible  begins  by  computing  the  effects  of  each  course  /  speed  change  on  ARIES 
trajectory.  The  advance,  transfer,  and  path  length  are  calculated  for  each  turn.  The  path 
length  required  for  the  speed  change  is  also  calculated,  using  Eqn.  5.8  above.  Whichever 
path  length  is  longest  determines  the  duration  of  the  course  /  speed  change  transient.  If 
the  course  change  is  significant,  the  turn  path  length  dominates.  Conversely,  when  minor 
course  changes  are  made,  the  dominant  consideration  becomes  the  distance  required  to 
reach  the  steady  state  speedy.  In  the  former  case,  ( Tj ,  7, )  are  found  by  displacing 

( A.,  7)  the  distance  due  to  the  effects  advance  and  transfer,  plus  the  distance  due  to 
currents  over  the  time  duration  of  the  turn.  For  the  latter  case,  ( Tj ,  }j  )  are  found  by 
displacing  ( A.,  7)  the  distance  due  to  the  effects  advance  and  transfer,  plus  the  additional 
distance  along  the  final  course  y/x  required  to  complete  the  speed  transient,  plus  the 

distance  due  to  currents  over  the  time  duration  of  the  turn.  These  are  shown  in  Fig.  28. 

A  similar  approach  is  used  for  the  final  turn  /  speed  change,  except  whereas  the  initial 
turn  projected  the  effects  forward  from  the  initial  known  position,  in  the  final  turn  the 
final  position  is  known  or  assumed  and  these  effects  are  projected  backwards  to  find 
(X2,T2). 

One  complication  to  the  above  methodology  is  that  the  effects  of  neither 
turn  can  be  calculated  directly  since  each  is  a  function  of  course  change,  a  quantity  that  is 
unknown  since  it  depends  on  the  combined  effects  of  both  turns.  For  example,  to  find 
(Xj,7j),  advance  and  transfer  data  are  applied  to  (Xi,Yi).  However,  advance  and  transfer 

depend  on  ARIES  course  between  (XvYx)  and  (X2,Y2),  which  depends  on  the  unknowns 
(Xj,7j).  To  overcome  this  complication,  an  iterative  solution  is  used  in  the  planning 
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process  starting  with  an  initial  guess  for  the  unknown  course  y/2 .  This  guess  is  the 
heading  i//2  such  that  the  current-corrected  course  over  ground  connects  (Xi,Yi)  to 
(X3,73),  ARIES’  initial  and  proposed  final  positions.  Using  this  initial  guess,  initial 
values  of  (Xj,7j  )  and  ( X2,Y2 )  are  obtained,  which  yield  a  refined  value  of  y/t .  Iteration 
continues  until  neither  X2  nor  V2  change  by  greater  than  1  meter  in  the  last  iteration. 

The  above  iterative  algorithm  fails  to  converge  when  ARIES  is  ahead  of 
the  target  vehicle  and  within  an  ARIES  turn  diameter  of  the  target  vehicle’s  projected 
track,  as  illustrated  in  Fig.  30. 


a.  b.  c. 

Figure  30.  ARIES  on  Target  Track  Causes  Planning  Non-Convergence.  Initial  Computation 
of  Transfer  (a).  First  Refinement  Iteration  (b).  Result  of  First  Iteration(c) 

In  this  case  the  planning  process  plans  a  final  turn  that  is  essentially  a  course  reversal,  but 
in  excess  of  pi  radians.  In  calculating  the  advance  and  transfer  of  any  turn,  the  planning 
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process  compares  the  initial  and  final  headings  and  computes  advance  and  transfer.  The 
difficulty  stems  from  the  computation  of  transfer  which,  unlike  advance,  has  sense. 
Advance  has  the  same  value  whether  a  course  change  of  given  magnitude  goes  to  the 
right  or  left  of  initial  course.  In  computing  transfer  for  a  given  course  change,  the 
direction  of  the  course  change  must  be  noted  so  that  the  planning  process  applies  transfer 
in  the  direction  of  the  turn.  For  the  case  of  ARIES  near  the  target  track,  the  final  course 
change  is  approximately  a  full  course  reversal  and  is  in  excess  of  pi  radians.  In  planning 
a  turn,  given  an  initial  and  final  course,  the  two  choices  are  to  turn  less  than  pi  radians,  in 
the  direction  of  the  next  course,  or  to  turn  greater  than  pi  radians,  in  the  opposite 
direction,  then  to  steady  on  the  new  course.  The  former  is  normally  desirable,  and  is  the 
method  used  in  the  planning  process.  On  the  initial  computation  of  transfer  for  the  final 
turn,  a  comparison  of  y/2  and  i//3  yields  a  value  of  transfer  with  the  correct  sense,  as 

shown  in  Fig.  30(a).  However,  on  the  first  iteration  to  refine  the  position  of  (X2,Y2),  i/a 
is  compared  with  the  just-determined  y/2 ,  which  is  based  on  the  initial  value  of  transfer. 
As  shown  in  Fig.  30(b),  the  comparison  of  y/2  with  i//2  yields  a  reversal  of  the  sense  for 
transfer,  due  the  shortest  turn  between  these  two  courses.  Applying  this  value  of  transfer 
to  (X3,73)  in  the  backwards  direction  to  locate  (X2,Y2 )  shifts  this  point  to  the  opposite 
side  of  the  target’s  track.  This  results  in  another  final  turn  in  excess  of  pi  radians,  and  in 
the  course  of  planning  this  turn  the  opposite  effect  occurs,  switching  (X2,Y2)  back  to  the 
original  side  of  target  track  and  never  converging.  To  prevent  non-convergence, 
whenever  ARIES  initial  position  is  within  30  meters  of  target  track  the  iterative  process 
of  locating  ( X1 ,  Yl )  and(  X2,Y2)  stops  after  one  iteration.  This  single  iteration  first  plans 
initial  and  final  course  changes  based  on  target  course  and  the  course  between  the  known 
locations  (Xi,Yi)  and (X3,73).  The  result  is  a  loss  of  a  few  meters  in  accuracy,  which 

may  be  reduced  during  subsequent  replanning  of  the  rendezvous  mission. 

If  ARIES  total  transit  time  exceeds  the  time  at  which  the  target  vehicle  is 
due  at  this  waypoint,  the  target’s  state  at  this  time  is  not  contained  in  ARIES  set  of 
reachable  states,  and  rendezvous  is  not  feasible.  In  this  case  the  time-optimal  rendezvous 
point  occurs  later,  further  down  the  target  vehicle’s  track.  Conversely,  if  the  calculated 
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ARIES  transit  time  is  less  than  the  time  that  the  target  vehicle  requires  to  reach  the  way 
point,  rendezvous  is  feasible  at  this  point,  albeit  suboptimally  as  ARIES  can  feasibly 
arrive  before  the  target.  In  this  case,  the  time  optimal  rendezvous  occurs  at  an  earlier 
time  and  location  along  the  target’s  track. 

Having  detennined  the  time  required  to  complete  both  course  /  speed 
changes  and  the  endpoints  of  the  straight  portion  of  the  trajectory,  t12,  the  available 

ARIES  transit  time  between  ( X2,Y2  )  and  ( A, ,  L )  is  computed  by  subtracting  the  time 
required  by  both  ARIES  course/speed  changes  from  the  time  that  the  target  reaches  the 
way  point.  The  final  step  in  determining  rendezvous  feasibility  is  to  compare  R{_2 ,  the 

distance  between  (Aj,Ij)  and  (X2,Y2 ),  to  RA,  the  maximum  distance  ARIES  could 
travel  in  along  i//,  from  (Xi ,YX)  and  ( X2,Y2  )  in  /,  2  while  correcting  for  prevailing 
currents.  In  the  time  optimal  case, 

Ra=R  1-2  (5-9) 

as  ARIES  reaches  the  rendezvous  point  at  the  earliest  possible  moment.  Locating  the 
time-optimal  rendezvous  point  therefore  consists  of  finding  the  zero  of 

Ra-Rx-2  (5-10) 

The  zero  is  located  iteratively  using  a  secant-method  algorithm  (Betts,  2001). 

d.  Locating  Remaining  ARIES  Way  Points 

The  process  of  locating  the  time-optimal  rendezvous  point  (X3,73),  the 
first  way  point  found  for  the  ARIES  rendezvous  mission,  also  locates  the  way  point  for 
beginning  the  final  course  /  speed  change  (X2,Y2)  as  an  intermediate  result.  The 
remaining  rendezvous  mission  way  points  are  added  prior  to  ( X2,Y2 )  as  GPS  fix  way 
points,  or  after  ( X3,  Y, )  to  guide  ARIES  along  the  target  vehicle’s  track.  In  this 
implementation  the  first  three  target  way  points  after  ( A, ,  7 )  were  used  in  ARIES 
rendezvous  mission  to  provide  a  sufficiently  long  rendezvous  communication  period. 
The  number  of  GPS  way  points  included  prior  to  rendezvous  is  a  function  of/?,  2 ,  which 
constitutes  the  majority  of  ARIES  pre-rendezvous  travel.  GPS  waypoint  planning 
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consists  of  dividing  the  straight  track  between  {Xx,Yx)  and  ( X2,Y2)  into  200  meter  long 
segments,  starting  at  (X2,Y2)  and  stepping  backwards  towards  X, ,  Yx .  ARIES  surfaces  for 
a  GPS  fix  once  in  each  200  meter  segment.  A  GPS  fix  is  also  planned  in  the  segment 
between  the  earliest  200  meter  segment  and  (XpFj)  if  that  segment  is  at  least  100  meters 

long,  which  provides  sufficient  time  for  the  surfacing  maneuver  and  course  correction 
following  the  fix. 

e.  Planning  Speeds 

As  shown  in  Fig.  23,  each  ARIES  mission  waypoint  is  specified  by  11 
parameters.  Having  detennined  the  values  in  the  first  two  columns  for  each  waypoint  in 
the  time  optimal  rendezvous  mission,  X  and  Y  coordinates,  the  remaining  are  then 
assigned.  The  next  two  columns  contain  Nrs  and  Nls ,  the  speed  commands  to  the  right 
and  left  thrusters  respectively,  which  detennine  ARIES  forward  speed  through  the  water 
u.  Since  the  relationship  between  propeller  speed  and  forward  speed  for  vehicles  such  as 
ARIES  is  typically  linear,  experimental  ARIES  data  was  used  to  establish  a  linear 
relationship  between  thruster  commands  and  commanded  speed  ucom : 

N,,Nrs=2A32ucom  (5.11) 

Identical  commands  are  sent  to  both  thrusters.  Experimentation  with  ARIES  showed  that 
its  maximum  speed  is  approximately  1.5  meters  per  second,  so  for  time-optimal 
rendezvous  waypoints  up  to  and  including  (X2,Y2)  speed  corresponding  to  1.5  meters  per 
second  is  commanded.  This  results  in  ARIES  using  maximum  speed  from  the  start  of  the 
rendezvous  mission  until  it  reaches  (X2,F2),  the  point  at  which  it  begins  its  deceleration 

to  match  target  speed.  For  way  points  after  ( X2,Y2),  the  speed  command  is  the  same  as 
the  target’s  speed. 

f  Setting  Way  Point  Timeouts 

ARIES  is  programmed  to  abort  its  mission  if  it  does  reach  its  way  point  in 
a  specified  time  period.  This  provides  for  mission  termination  in  the  event  of  a  vehicle 
control  or  navigation  failure.  This  feature,  controlled  by  the  parameter  in  the  final 
column  of  the  way  point  file,  was  left  unmodified  for  this  implementation,  so  it  was 
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necessary  to  assign  appropriate  values  to  this  parameter.  Values  of  approximately  150% 
of  expected  time  to  reach  each  waypoint  were  assigned  to  each,  a  rule  validated  by 
previous  ARIES  research. 

g.  Planning  GPS  Fixes 

As  discussed  above,  GPS  fixes  may  be  planned  prior  to  the  rendezvous 
point.  For  each  segment  containing  a  GPS  fix,  the  value  in  column  8  is  set  to  “1”  and  the 
value  in  column  9  is  set  to  30,  to  allow  a  30  second  period  in  which  to  surface  and  obtain 
the  fix. 

h.  Setting  Watch  Radii 

This  parameter  determines  when  ARIES  is  considered  to  have  reached  the 
way  point.  When  ARIES  approaches  the  way  point  within  this  distance,  or  crosses  a  line 
perpendicular  to  the  track  connecting  the  current  and  previous  way  points  and  tangent  to 
the  watch  radius  circle,  the  next  way  point  is  activated  and  ARIES  begins  driving  towards 
it.  A  typical  value  for  this  parameter  is  10  meters,  the  value  which  is  set  for  most  way 
points  and  the  value  assumed  to  be  used  by  the  target  vehicle.  The  exceptions  are 
(X,,72)  and  (X3,73),  which  define  the  entry  into  and  exit  from  the  final  turn.  In  order  to 
accurately  control  ARIES  trajectory  during  the  final  turn  into  the  rendezvous,  these  watch 
radii  are  set  to  1  meter. 

i.  Setting  Depths  and  Altitudes 

These  parameters  are  set  in  columns  5-7  of  the  way  point  file.  Depth 
mode  is  selected  in  column  5  to  maintain  ARIES  at  a  constant  depth,  which  is  set  to  3 
meters  in  column  6.  Since  altitude  mode  is  not  set  in  column  5,  column  7  represents 
unused  data  for  nonnal  depth-mode  ARIES  missions.  For  this  implementation  this 
column  is  used  to  indicate  whether  ARIES  is  expected  to  be  rendezvoused  with  the  target 
at  this  time,  an  indication  that  triggers  other  ARIES  actions.  Therefore,  for  all  waypoints 
after  (X2,Y2)  this  value  is  set  to  “7”  to  indicate  rendezvous  should  be  in  progress. 
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F igure  31.  Watch  Radius 

j.  Writing  the  Mission  to  File 

Once  all  rendezvous  mission  parameters  have  been  assigned,  the  mission 
is  checked  for  feasibility  by  verifying  that  each  planned  way  point  lies  within  the 
previously  determined  area  of  operations.  Once  checked,  the  mission  is  written  to  the 
way  point  fde  “RdvzTrack.ouf ’,  which  is  opened  and  executed  by  the  RExec  process. 

6.  Planning  Energy-Optimal  Rendezvous 

The  steps  to  planning  an  energy-optimal  rendezvous  are  a  superset  of  the  steps  for 
planning  a  time-optimal  rendezvous.  All  the  time-optimal  planning  steps  -  finding  the 
time  optimal  rendezvous  point,  planning  GPS  fixes,  setting  speeds  and  other  parameters, 
checking  for  feasibility,  and  writing  the  mission  to  file  -  are  taken;  however  energy- 
optimal  rendezvous  planning  involves  additional  complexity  requiring  additional 
intermediate  steps. 

a.  Bounding  the  Energy-Optimal  Rendezvous  Point 

Whereas  the  time  optimal  rendezvous  point  was  uniquely  defined  as  the 
position  of  the  target  vehicle  at  the  earliest  time  for  which  the  target  state  was  included  in 
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ARIES  set  of  reachable  states,  the  energy  optimal  rendezvous  point  is  one  of  many 
possible  reachable  states.  This  is  so  because,  by  its  nature,  the  energy  optimal 
rendezvous  involves  closing  the  target  at  a  slower,  more  energy-efficient  speed.  As  was 
the  case  with  time-optimal  rendezvous,  the  target  state  is  not  included  in  the  set  of 
reachable  states  prior  to  the  time-optimal  rendezvous  point,  therefore  the  time-optimal 
rendezvous  point  sets  the  earliest  possible  bound  for  the  energy-optimal  rendezvous. 
This  provides  the  planning  process  a  wide  range  of  possible  rendezvous  points,  all  of 
which  lie  after  the  time  optimal  rendezvous  point. 

The  energy  optimal  rendezvous  point  lies  somewhere  in  a  single  region 
that  is  bounded  by  this  point  and  another  similar  point.  Practical  limits  on  slow-speed 
vehicle  controllability  define  this  latest-possible  bound  on  energy  optimal  rendezvous 
when  it  occurs  prior  to  end  of  target  mission.  Because  vehicles  such  as  ARIES  use 
control  surfaces  to  generate  forces  to  control  attitude,  course,  and  depth;  and  because 
these  forces  are  proportional  to  the  square  of  forward  speed,  there  exists  a  practical 
minimum  speed  umjn  below  which  the  forces  generated  by  its  control  surfaces  can  no 

longer  overcome  buoyant  forces,  surface  suction  forces,  or  other  disturbances.  This 
minimum  speed  sets  a  lower  bound  on  propulsion  power,  and  results  in  an  upper  bound 
on  time  for  energy-optimal  rendezvous.  Minimum  ARIES  speed  sets  a  lower  bound  on 
minimum  energy  used  for  rendezvous: 

E=  '\  A  +  BulJl  =  t,(A  +  Buii,)  (5.12) 

1=0 

where  t:.  is  the  time  of  rendezvous,  A  is  vehicle  hotel  load  in  watts,  and  B  is  the 

propulsion  power  coefficient  in  watt-second3  /  meter3 .  Since  the  tenn  in  parenthesis  is 
constant,  the  minimum  energy  to  rendezvous  is  a  linear  function  of  time.  As  a  result,  if 
there  exist  multiple  opportunities  to  rendezvous  with  ARIES  closing  the  target  at  umin ,  all 

opportunities  after  the  first  opportunity  require  more  energy.  As  a  result,  the  earliest 
rendezvous  time  for  ARIES  using  its  minimum  speed  throughout  the  closure  to 
rendezvous  sets  a  latest  possible  time  for  minimum-energy  rendezvous.  The  minimum 
energy  rendezvous  point  lies  between  the  first  time  that  the  target’s  state  is  included  in 
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ARIES  set  of  reachable  states  at  maximum  ARIES  speed  and  the  first  time  it  is  included 
at  ARIES  minimum  speed,  as  shown  in  Fig.  32. 


Outer  Boundary  of 
Reachable  States 
At  ARIES  Max  Speed 


Target  Track 


Earliest 

Possible 


Rendezvous 


Outer  Boundary  of 
Reachable  States 
At  ARIES  Min  Speed 


•  ARIES  Initial  Position  • 


a.  b. 

Figure  32.  Earliest  Possible  Energy-Optimal  Rendezvous  (a).  Latest  Possible  Energy 

Optimal  Rendezvous  (b) 

There  are  two  exceptions  to  the  above  result.  First,  if  the  target  vehicle’s 
mission  terminates  prior  to  the  time  that  ARIES  could  reach  it  at  minimum  speed  then 
obviously  the  latest  possible  rendezvous  time  is  the  end  of  the  target’s  mission.  Second, 
in  a  similar  situation,  if  the  target  continuously  opens  ARIES  position  at  a  speed  higher 
than  umin ,  ARIES  cannot  reach  the  target  before  the  end  of  the  target  mission.  However, 

this  is  unlikely  since  target  vehicles  are  assumed  to  remain  in  within  a  bounded 
geaographical  area,  meaning  their  overall  speed  away  from  ARIES  is  likely  to  be  low. 

Bounding  the  times  of  possible  minimum  energy  rendezvous  conserves 
computational  resources  required  for  the  energy  optimal  rendezvous  by  limiting  the  size 
of  the  space  to  be  search  for  a  solution. 
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b.  Locating  the  Energy-Optimal  Rendezvous  Point 
This  process  uses  the  same  subroutines  used  to  find  the  time-optimal 
rendezvous  point.  First,  the  time-optimal  rendezvous  point  is  located  on  the  target 
vehicle’s  track,  marking  the  earliest  possible  time  for  energy  optimal  rendezvous. 

After  this  step  the  sequence  of  steps  for  planning  the  energy-optimal 
rendezvous  trajectory  departs  from  the  time-optimal  sequence.  The  next  step  in  the 
energy-optimal  planning  process  is  to  identify  the  latest  possible  energy-optimal 
rendezvous.  The  same  algorithm  is  used,  except  whereas  the  earliest  time  was  identified 
by  setting  ARIES  speed  to  its  maximum  value  of  1 .5  meters  per  second,  the  search  for 
the  latest  time  is  conducted  using  ARIES  minimum  speed  of  1.0  meters  per  second. 

Having  defined  the  portion  of  the  target’s  track  containing  the  minimum 
energy  rendezvous  point,  the  track  is  sampled  to  determine  the  energy  required  to 
rendezvous  at  each  sample  point.  For  each  sample  point  the  speed  to  reach  that  point  is 
computed  as  trajectory  path  length  between  ARIES  and  the  point,  divided  by  the  time  the 
target  vehicle  will  be  at  the  point.  The  energy  required  by  the  rendezvous  trajectory  to 
that  point  is  then  calculated  for  each  point  as 

E  =  (A  +  Bu1)t  (5.13) 

and  the  minimum  energy  rendezvous  point  is  identified  as  the  point  having  the  lowest 
value  of  E. 

Once  the  minimum  energy  point  is  identified,  the  planning  process  plans 
the  trajectory  from  ARIES  position  to  the  rendezvous  point.  The  process  is  similar  to  that 
of  the  time-optimal  case,  which  used  a  constant  speed  to  iteratively  locate  the  rendezvous 
point.  However,  in  this  case  the  rendezvous  point  is  held  constant  while  the  course  and 
speed  changes  necessary  to  reach  the  point  are  solved  iteratively. 

Having  determined  the  energy-optimal  rendezvous  point,  the  remainder  of 
the  planning  process  is  identical  to  that  for  the  time-optimal  rendezvous.  Additional  way 
points  are  added  to  the  mission  and  waypoint  parameters  are  set  for  each  waypoint,  only 
difference  being  that  ARIES  speed  command  prior  to  the  rendezvous  point  is  a  lower, 
energy-efficient  speed  rather  than  maximum  attainable  speed.  The  mission  is  checked  for 
feasibility,  and  written  to  the  way  point  file  RdvzTrack.out. 
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I.  STATE  MACHINE 

Having  provided  ARIES  the  capability  to  autonomously  reconfigure  its  operations 
by  planning  new  missions  in  response  to  requests  by  other  vehicles,  it  was  necessary  to 
add  another  layer  of  logic  above  that  of  baseline  ARIES.  The  form  selected  was  a  finite 
state  machine,  illustrated  in  Fig.  33.  The  finite  state  machine  is  a  representation  of  a 
process  consisting  of  states  and  transitions  (Hatley,  Hruschka,  and  Pirbhai,  2000).  In  the 
ARIES  state  machine,  each  state  is  a  stage  of  the  rendezvous  process.  Associated  with 
each  state  are  actions  taken  by  the  vehicle.  Transitions  between  states  occur  in  response 
to  events  sensed  by  the  vehicle.  Each  state  is  responsive  to  a  specific  set  of  events,  with 
no  action  taken  for  events  not  associated  with  that  state.  Each  state  also  has  an  associated 
set  of  transitions  it  may  take  to  the  next  state.  The  finite  state  machine  provides  a  clear 
framework  upon  which  to  define  the  logic  of  the  rendezvous  process,  and  provides  a  high 
level  of  control  over  the  process.  This  is  essential  since  it  is  now  necessary  to  automate  a 
multi-state  ARIES  mission,  containing  both  previous  ARIES  processes  as  well  as  new 
and  modified  processes. 

The  state  machine  comprises  a  new,  third  layer  of  control  above  two  layers  that 
existed  in  the  vehicle  prior  to  this  work.  The  three-layer  approach  is  common  in  robotics 
software  architecture,  with  the  Rational  Behavior  Model  (RBM)  (Kwak,  McGee,  and 
Bihari,  1992)  representing  one  implementation.  In  ARIES  the  lowest  layer, 
corresponding  the  execution  level  of  the  RBM,  contains  the  autopilots  that  control  the 
vehicle’s  fins  and  rudders  to  keep  the  vehicle  on  prescribed  course  and  depth,  which 
reside  in  the  process  RExec.  The  middle  layer,  corresponding  the  RBM  tactical  level, 
contains  the  mission  control  functions,  also  resident  in  the  RExec  process.  This  logic 
interprets  the  mission  script  and  waypoint  files  and  sequences  the  vehicle  though  the 
mission  defined  in  these  files.  Mission  parameters  contained  in  these  files  are  provided 
to  the  execution  level  for  action.  The  state  machine,  representing  the  strategic  level  of 
the  RBM,  sequences  ARIES  through  multiple  missions  during  its  operation  and  performs 
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Figure  33.  ARIES  Finite  State  Machine,  Showing  States  and  Transitions 
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T  erminateTrack.  out 


supporting  functions  such  as  initiation  and  interpretation  of  communications  and 
initiation  of  mission  planning.  This  hierarchy  is  shown  in  Fig.  34. 


Figure  34.  ARIES  Three-Layer  Rendezvous  Software  Architecture 

The  state  machine  is  implemented  in  ARIES  RExec  code  by  defining  the  variable 
“State”  and  changing  its  value  whenever  criteria  are  met  for  transition  to  the  next  state. 
There  are  seven  possible  states,  and  with  transition  criteria  and  actions  defined  for  each. 
At  each  125  millisecond  cycle  of  RExec’ s  main  control  loop  the  transition  criteria  are 
examined.  If  satisfied,  the  state  transition  occurs  by  the  next  cycle. 

1.  Loiter 

LOITER  is  ARIES’s  initial  state  upon  starting  the  RExec  process. 
a.  Actions 

While  in  LOITER,  ARIES  follows  the  way  point  file  “Track.out”.  This 
behavior  is  the  same  as  baseline  ARIES  behavior,  except  for  mission  timeout,  providing 
backward  compatibility  with  baseline  ARIES  missions.  To  run  a  baseline  ARIES 
mission  under  rendezvous  software  architecture,  one  need  only  define  the  mission  in  the 
mission  script  file  script.d  and  way  point  file  Track.out  and  run  the  mission  under  RExec 
without  issuing  any  rendezvous  requests  to  ARIES. 
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For  rendezvous  missions  the  way  point  file  Track.out  defines  ARIES  loiter 
location,  courses  and  speeds.  In  general  ARIES  loiters  at  low,  energy-efficient  speeds, 
fixing  its  position  periodically  with  GPS. 

Any  transition  to  LOITER  reactivates  the  way  point  file  Track.out. 

b.  Transitions 

While  in  LOITER,  ARIES  checks  the  status  of  the  rendezvous  request 
queue  each  125  millisecond  cycle  of  the  RExec  control  loop.  ARIES  remains  in  the 
LOITER  state  as  long  as  the  queue  remains  empty,  transitioning  to  the  mission  planning 
PLAN  MSN  state  as  soon  as  a  request  appears  in  the  queue. 

There  are  three  transitions  into  the  LOITER  state.  If  ARIES  is  in  the 
RENDEZVOUS  state,  the  LOITER  state  is  entered  upon  completion  of  the  rendezvous. 
If,  while  attempting  to  initiate  rendezvous  communications,  ARIES  cannot  contact  the 
target  vehicle,  it  returns  to  the  LOITER  state.  If  the  rendezvous  planning  process 
produces  an  infeasible  rendezvous  mission,  the  state  returns  to  LOITER.  Note  that 
whenever  rendezvous  requests  exist  in  the  queue  prior  to  ARIES  entering  the  LOITER 
state,  ARIES  immediately  transitions  to  the  PLAN  MSN  state. 

2.  Plan  Mission 

a.  Actions 

Upon  entering  the  PLAN  MSN  state,  RExec  writes  the  parameters 
contained  in  the  next  rendezvous  request  in  the  queue  to  RExec  shared  memory.  This 
makes  the  request  available  to  the  rendezvous  mission  planning  process  RPlan.  RExec 
then  triggers  RPlan ’s  proxy,  which  frees  the  RPlan  process  from  its  normal  “receive 
blocked”  execution-suspended  condition  and  begins  the  mission  planning  process.  On 
subsequent  control  loop  cycles  RExec  monitors  the  status  of  the  planning  process,  which 
is  indicated  by  values  written  to  RPlan  shared  memory  by  the  RPlan  process,  and  take 
actions  based  on  the  outcome  of  the  planning  process. 

b.  Transitions 

There  are  five  transitions  into  the  PLAN  MSN  state.  The  previously 
discussed  transition  from  the  LOITER  state  occurs  for  initial  planning  of  a  mission  in  the 
rendezvous  request  queue.  The  remaining  four  are  due  to  replanning  a  rendezvous 

mission  in  progress  in  order  to  improve  navigational  accuracy.  If  a  subsequent 
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rendezvous  request  is  received  from  the  same  target  vehicle  that  ARIES  is  closing  for 
rendezvous,  but  before  the  rendezvous  commences,  the  updated  target  position  data 
contained  in  the  request  is  used  to  replan  the  mission  by  reentering  the  PLAN  MSN  state. 
Similarly,  if  ARIES  is  unable  to  establish  rendezvous  communications  with  the  target 
vehicle  after  arrival  at  the  rendezvous  point,  it  queries  the  target  for  its  position.  The 
position  contained  in  the  response  to  the  query  is  used  to  replan  the  mission.  Whereas 
these  allow  replanning  to  correct  target  vehicle  position,  there  are  two  instances  when  the 
rendezvous  mission  is  replanned  to  correct  for  ARIES  position.  Whenever  ARIES 
obtains  a  new  GPS  fix,  subject  to  a  restriction  that  no  GPS  fix  has  been  obtained  within  a 
specified  time  period,  replanning  occurs.  Finally,  replanning  occurs  if  ARIES  fails  to 
obtain  a  scheduled  GPS  fix.  Although  in  such  cases  no  new  position  data  is  obtained  to 
improve  the  accuracy  of  ARIES’  position,  disturbances  such  as  currents  and  speed 
variations  will  perturb  ARIES  as  it  drives  down  its  track  towards  rendezvous.  Periodic 
replaning  allows  ARIES  to  adjust  its  rendezvous  plan  to  ensure  it  meets  the  target  at  the 
rendezvous  point. 

There  are  two  transitions  out  of  the  PLAN  MSN  state.  As  discussed 
above,  when  the  rendezvous  planning  process  produces  an  infeasible  mission,  state 
transitions  to  LOITER.  In  addition,  the  rendezvous  request  is  cleared  from  the  queue  so 
that  the  next  request  may  be  acted  upon.  On  the  other  hand,  if  the  mission  planning 
process  produces  a  feasible  mission,  RExec  opens  the  rendezvous  mission  way  point  file 
RdvzTrack.out,  reads  the  contents  into  memory  to  begin  executing  the  rendezvous 
mission,  and  ARIES  enters  the  CLOSING  state. 

3.  Closing 

ARIES  is  in  the  CLOSING  state  from  the  time  it  begins  executing  a  rendezvous 
mission  until  it  reaches  the  rendezvous  point,  with  the  exception  of  transitions  to  the 
PLAN  MSN  state  for  replanning. 

a.  Actions 

While  closing  the  rendezvous  point  ARIES  monitors  replanning  criteria. 
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b.  Transitions 

The  CLOSING  state  is  entered  upon  successful  completion  of  mission 
planning.  Transition  out  of  the  closing  state  occurs  for  replanning  or  arrival  at  the 
rendezvous  point. 

Replanning  in  response  to  a  subsequent  rendezvous  request  from  the 
current  target  vehicle  occurs  when  the  queue  management  process  detennines  that  this 
has  occurred. 

Replanning  in  response  to  a  good  GPS  fix  begins  after  an  unbroken  ten 
second  period  of  receiving  three  or  more  GPS  satellites,  if  no  GPS  fix  has  been  obtained 
in  the  previous  60  seconds.  The  60  second  period  ensures  that  once  such  a  GPS  fix 
period  exceeds  10  seconds,  the  planning  process  is  not  repeatedly  triggered  each  RExec 
cycle.  The  ten  second/three  satellite  criterion  is  based  on  previous  ARIES  navigation 
system  performance.  Note  that  failure  to  meet  this  fix  criterion  does  result  in  rejection  of 
the  GPS  fix  data.  Although  replanning  does  not  occur  if  the  criteria  are  not  met,  ARIES 
navigation  is  still  updated  by  the  GPS  data  and  the  correction  of  ARIES  position  still 
occurs  in  the  navigation  filter.  This  updated  navigation  data  will  then  be  applied  to  the 
next  mission  replanning  event. 

If  a  GPS  fix  satisfying  the  above  criteria  is  not  obtained,  a  30  second  timer 
is  started.  If  no  GPS  fix  is  obtained  in  this  period,  replanning  commences. 

Upon  arrival  at  ( X2,Y2),  the  start  of  the  final  course/speed  change,  ARIES 
transitions  from  the  closing  state  to  the  initiate  rendezvous  or  INIT  RDVZ  state.  Arrival 
at  this  point  is  signaled  by  the  activation  of  the  way  point  (X3,73).  It,  and  all  subsequent 

way  points  in  the  rendezvous  mission,  contain  the  value  “7”  for  the  6th  way  point 
parameter.  This  is  the  state  machine  transition  signal. 

4.  Initiate  Rendezvous 

a.  Actions 

Upon  entry  into  this  state,  ARIES  attempts  to  initiate  rendezvous 
communications  with  the  target  vehicle  which  should  be  nearby. 
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b.  Transitions 

The  INIT  RDVZ  state  is  entered  upon  activation  of  the  rendezvous  point 
as  the  next  ARIES  way  point. 

The  state  is  exited  either  when  rendezvous  communications  are 
established  with  the  target  vehicle,  or  after  no  rendezvous  communications  occur  after  60 
seconds. 

5.  Rendezvous 

a.  Actions 

In  the  rendezvous  or  RDVZ  state,  ARIES  conducts  rendezvous 
communications  while  it  continues  to  follow  the  rendezvous  mission. 

b.  Transitions 

The  state  is  entered  at  the  start  of  rendezvous  communications,  and  is 
exited  at  their  completion. 

6.  Query  Position 

Should  ARIES  be  unable  to  establish  rendezvous  communications  within  60 
seconds  of  entering  the  INIT  RDVZ  state,  it  enters  the  query  position  or  QUERY  POSIT 
state  and  attempts  to  locate  the  target  vehicle,  the  assumption  being  that  it  is  not  in  the 
immediate  vicinity,  outside  the  limited  range  of  the  high-bandwidth  rendezvous 
communications  device. 

a.  Actions 

ARIES  transmits  a  query  to  the  target  vehicle,  asking  it  to  send  an  updated 
rendezvous  request  with  which  ARIES  may  plan  a  new  rendezvous  mission. 

b.  Transitions 

The  state  is  entered  at  the  expiration  of  a  60  second  timer  from  the  INIT 
RDVZ  state.  It  is  exited  if  no  response  to  the  query  is  received.  In  this  case,  ARIES 
enters  the  LOITER  state.  If  a  response  is  received,  the  state  becomes  PLAN  MSN. 

7.  Terminate 

When  the  operation  involving  ARIES  and  its  network  of  sensor  vehicles  reaches 
its  scheduled  completion,  ARIES’  logic  must  tenninate  this  phase  of  the  operation  and 
activate  the  final  phase:  returning  for  recovery.  To  do  so,  ARIES  enters  the 
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TERMINATE  state.  This  state  is  unique  in  that  it  can  be  entered  from  any  state,  which 
provides  a  “fail-safe”  feature  to  break  ARIES  out  of  whatever  phase  of  operations  it  may 
be  involved  in. 

a.  Actions 

Upon  entry  into  the  TERMINATE  state,  ARIES  activates  the  way  point 
file  TerminateTrack.out,  which  brings  ARIES  to  its  recovery  point.  Periodic  GPS  fixes 
are  obtained  enroute  to  maintain  accurate  navigation. 

b.  Transitions 

The  state  is  entered  upon  expiration  of  the  mission  timer.  There  are  no 
transitions  out  of  the  state. 

8.  Receipt  of  Rendezvous  Requests  and  Other  Modem  Messages 

The  asynchronous  operations  of  the  vehicle  network  result  in  rendezvous  request 
transmission  at  any  time.  The  state  machine  ensures  that  ARIES  acts  on  requests  only 
when  appropriate,  however  incoming  requests  must  be  properly  handled  at  any  stage  of 
the  operation.  To  ensure  this  occurs,  the  state  machine  portion  of  the  RExec  process 
takes  the  same  action  on  incoming  requests  regardless  of  state.  Within  the  RExec  8  Hz 
control  loop,  immediately  before  the  state  machine  block  of  code,  the  RExec  process 
reads  modem  shared  memory  to  check  for  arrival  of  any  new  modem  message.  Arrival  of 
a  new  message  is  signaled  by  the  modem  process  Rfim  setting  one  of  its  shared  memory 
variables,  an  integer  that  serves  as  a  flag,  to  TRUE.  If  set,  the  data  contained  in  the 
message  is  read  from  modem  shared  memory  into  RExec. 

If  the  message  is  a  rendezvous  request  or  pertains  to  rendezvous  communications, 
the  value  of  the  RExec  variable  “SMEvent”  ,  or  state  machine  modem  event,  is  set  to 
signal  this  event.  It  can  signal  four  different  events:  receipt  of  a  rendezvous  request 
requiring  immediate  planning,  receipt  of  a  rendezvous  request  to  be  queued  for  later 
planning,  start  of  rendezvous  communications,  and  completion  of  rendezvous 
communications.  The  value  of  SMEvent  is  an  input  to  the  state  machine  to  potentially 
trigger  a  state  transition. 

If  the  modem  message  is  a  rendezvous  request,  the  checksum  is  validated  and  the 
request  written  to  the  queue. 
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Any  abort  command  received  by  the  modem  process  triggers  a  bock  of  code 
which  immediately  brings  ARIES  to  the  surface  and  shuts  it  down,  bypassing  the  state 
machine. 

If  the  message  is  a  position  query,  it  is  processed  by  the  modem  Rfm  process 
without  involving  the  RExec  process. 

9.  Initiating  Modem  Transmissions 

The  state  machine  periodically  generates  outgoing  modem  transmissions. 
Because  ARIES  carries  only  its  Benthos  modem,  with  no  high  data-rate  rendezvous 
communications  equipment,  this  modem  serves  both  command  and  control  and  simulated 
data  functions.  As  a  result,  all  communications  go  through  this  one  modem. 

As  discussed  previously,  ARIES  transmits  to  attempt  to  begin  rendezvous 
communications,  and  transmits  to  query  for  target  position  if  rendezvous  communications 
do  not  start  within  the  expected  time.  In  an  actual  operation,  as  opposed  to  this 
demonstration,  the  former  would  be  transmitted  as  short-range  data  communications  and 
the  latter  as  long-range  command  and  control  communications. 

For  the  purposes  of  this  development  and  demonstration  additional  modem  status 
messages  are  initiated  by  the  state  machine  to  supplement  the  above  transmissions  to 
better  track  vehicle  status,  although  they  would  not  be  used  in  an  operational  setting. 
These  transmissions  are  shown  in  Table  1. 

J.  MISSION  ACTIVATION 

The  baseline  ARIES  execution  process  Exec  opened  one  way  point  file  at  the  start 
of  its  mission,  loading  data  into  memory  and  performing  necessary  calculations  only 
once.  Calculations  include  such  parameters  as  courses  and  lengths  of  each  segment,  time 
out  for  the  first  way  point  based  on  ARIES  initial  position,  and  whether  the  first  way 
point  is  too  close  and  should  be  skipped.  The  RExec  process  required  the  flexibility  to  do 
this  mid-operation,  whenever  a  new  mission  is  activated  by  the  state  machine.  To  this 
end,  these  functions  were  removed  from  RExec  and  rewritten  as  a  distinct  subroutine  of 
RExec  which  could  be  called  whenever  necessary,  taking  the  way  point  file  name  and 
ARIES  position  as  input  arguments. 
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MODEM  TRANSMISSION 

TRANSLATION 

“ CLOSING ” 

Successful  completion  of  the  mission 

planning  or  replanning. 

“INFEAS RDVZ,  LOITER ” 

Mission  planning  resulted  in  an  infeasible 

rendezvous  mission  plan. 

"QUERY POSIT  TIMEOUT ” 

Rendezvous  attempt  abandoned  after  no 

rendezvous  communications  established  and 

no  response  received  in  response  to  query 

for  target  vehicle  position. 

"RDVZ  COMMS” 

Entry  into  the  rendezvous  state 

"MISSION  TIMEOUT,  TERMINATING” 

Overall  mission  timeout. 

Table  1 .  Modem  Messages  Initiated  by  the  State  Machine 


K.  RENDEZVOUS  QUEUE  AND  QUEUE  MANAGEMENT 

The  rendezvous  queue  is  an  integer  array  sized  to  store  five  rendezvous 
parameters  for  each  of  four  rendezvous  requests.  The  size  of  the  queue  was  based  on  an 
assumption  that  no  more  than  four  target  vehicles  would  be  involved  in  the  operation,  and 
due  to  queue  management  which  allows  only  one  queued  request  per  target  vehicle. 
Requests.  The  five  parameters  per  request  are  target  number,  waypoint,  progress  towards 
way  point,  time  stamp,  and  check  sum/optimization  objective. 

The  first  queue  management  function,  WriteQueue,  writes  incoming  the  requests 

to  the  queue  when  they  appear  in  modem  shared  memory.  Because  subsequent  requests 

from  a  queued  target  vehicle  represent  updated  navigation  information  and  not  a  request 

for  an  additional  rendezvous,  the  process  of  writing  to  the  queue  also  involves  checking 

the  queue  for  a  previous  request  from  this  target  vehicle.  If  no  previous  request  is  queued 

for  this  vehicle,  the  request  is  written  to  the  bottom  of  the  queue,  otherwise  the  previously 

queued  request  is  overwritten.  WriteQueue  returns  a  value  which  becomes  the  value  of 

the  state  machine  variable  SMEvent.  If  the  queue  is  empty,  there  are  no  pending 
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rendezvous  requests  and  the  incoming  request  should  be  sent  to  the  mission  planning 
process  immediately.  Similarly,  if  the  sending  vehicle’s  previous  request  is  at  the  top  of 
the  queue,  ARIES  is  in  the  process  of  rendezvousing  with  the  sender  of  the  incoming 
request.  As  long  as  the  present  state  is  not  RENDEZVOUS,  the  incoming  request  should 
be  processed  and  the  rendezvous  mission  replanned.  For  these  two  cases  SMEvent  is  set 
equal  to  “2”,  which  triggers  the  mission  planning  process  if  ARIES’  state  is  LOITER, 
CLOSING,  or  QUERY  POSIT.  Otherwise  it  returns  the  value  “6”,  which  causes  the 
contents  of  the  request  to  be  written  to  the  queue. 

The  queue  management  function  “CheckQueue”  is  called  by  RExec  while  in  the 
loiter  state  to  initiate  mission  planning.  CheckQueue  returns  “1”  if  there  is  a  pending 
rendezvous  request  in  the  queue,  otherwise  it  returns  “0”. 

The  queue  management  function  “ClearQueue”  removes  the  top  request  from  the 
queue  and  promotes  all  pending  requests.  It  is  called  upon  nonnal  completion  of  a 
rendezvous,  upon  completion  of  the  mission  planning  when  the  mission  is  infeasible,  and 
after  an  unsuccessful  rendezvous  when  ARIES  fails  to  make  contact  with  the  target 
vehicle  and  receives  no  response  to  its  query  for  target  vehicle  position. 

L.  MODEM 

The  baseline  modem  process  “fm”  was  rewritten  as  “Rfm”  to  support  rendezvous 
operations.  Its  vocabulary  was  modified  to  remove  unused  message  formats  and  to 
provide  those  required.  Recognized  incoming  messages  are  shown  in  Table  2. 
Recognized  message  headers  are  “RVS”  and  “RVQ”,  corresponding  to  “set”  commands 
and  queries,  respectively.  The  next  field  in  the  message  is  the  command,  which  is 
followed  by  command  parameters  in  the  case  of  a  rendezvous  request.  Memory  variables 
were  also  added  to  store  message  parameters.  Receipt  of  any  of  these  messages  causes 
the  contents  to  be  written  to  Rfm  shared  memory,  and  for  a  flag  to  be  set  in  shared 
memory  to  signal  the  RExec  process  that  a  new  message  has  been  received.  RExec  clears 
this  flag  after  reading  the  message  parameters  from  Rfm  shared  memory. 

The  modem  process  was  also  modified  to  allow  the  RExec  process  to  initiate 
modem  transmissions,  as  is  necessary  when  ARIES  attempts  to  contact  the  target  vehicle 

or  transmit  status  messages.  This  required  the  Rfm  process  to  monitor  the  contents  of 
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MESSAGE 

TRANSLATION 

'  R  VS,  RE  Q,a,b,c,d,e” 

Rendezvous  request  from  target  vehicle  a,  which  is  enroute  to 
its  bth  way  point  and  is  located  c  thousandths  of  the  total 
length  of  this  leg  down  track  at  time  d  seconds.  The  sum  of 

the  integers  a-d  is  e.  The  sign  of  e  is  positive  for  a  time- 

optimal  rendezvous  and  negative  for  an  energy-optimal 

rendezvous. 

“RVS,CS” 

Start  of  simulated  rendezvous  communications 

“RVS,CC” 

Completion  of  simulated  rendezvous  communications 

■R  VS,  ABORT” 

Abort.  ARIES  stops  and  surfaces. 

■RVQ,  POSIT” 

Query  ARIES  X,Y  position 

Table  2.  Incoming  Messages  Recognized  by  Modem  Process 


RExec  shared  memory  as  well  as  modem  output.  Rfm  checks  the  status  of  a  flag  in 
RExec  shared  memory  which  signals  the  presence  of  an  outgoing  message,  at 
approximately  20  Hz.  When  this  flag  is  set,  Rfm  reads  the  message  from  RExec  shared 
memory,  clears  the  flag,  and  sends  the  message  to  the  modem  to  be  transmitted. 

M,  SHARED  MEMORY 

Shared  memory  is  the  primary  method  of  inter-process  communications  in 
ARIES.  Modifications  to  shared  memory  for  rendezvous  operations  consisted  of  creating 
a  new  shared  memory  segment  for  the  planning  process  RPlan,  and  adding  new  variables 
to  the  existing  execution  and  modem  process  shared  memory  segments.  A  diagram  of 
shared  memory  segments  is  shown  in  Fig.  35. 
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Figure  35.  Shared  Memory  Segments  and  Variables 

The  RExec  process  makes  data  available  to  the  modem  processes  Rfm  and  RPlan. 
Data  made  available  to  the  modem  consists  of  a  flag  to  signal  the  RExec  has  generated  an 
outgoing  modem  message  and  the  message  itself.  RExec  sets  the  flag  and  Rfm  clears  the 
flag  once  it  reads  the  message.  RExec  also  makes  data  necessary  for  mission  planning 
available  to  RPlan.  This  data  consists  of  ARIES  position,  course  and  speed,  target 
parameters  for  the  target  to  be  rendezvoused  with,  and  clock  time.  RExec  shared  memory 
also  makes  provisions  for  passing  measured  current  set  and  drift,  although  measurement 
of  these  parameters  is  not  yet  implemented  in  RExec  code. 

Rfm  shared  memory  provides  a  flag  for  modem  messages  similar  to  that  in  RExec 
shared  memory.  It  is  cleared  by  the  RExec  process  once  the  incoming  message  is  read  by 
RExec.  The  remaining  Rfm  shared  memory  variables  store  the  data  contained  in  the 
incoming  message. 
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RPlan  shared  memory  contains  flags  to  indicate  that  the  mission  plan  generated 
by  the  planning  process  is  ready,  and  whether  it  is  feasible.  The  plan  ready  flag  is  cleared 
by  RExec  after  it  reads  the  flag.  Additionally,  RPlan  shared  memory  contains  the  process 
identification  of  its  proxy.  This  value  must  be  provided  to  the  RExec  process  in  order  for 
RExec  to  trigger  RPlan’ s  proxy  to  start  the  planning  process  for  each  rendezvous  request. 

N.  SYSTEM  IN-LAB  TESTING 

The  extensive  modifications  to  ARIES  software  required  significant  debugging 
and  verification  of  proper  perfonnance.  New  features  and  processes  were  written  and 
tested  as  isolated  modules.  However,  meaningful  complete  testing  of  the  integrated 
system  of  existing  and  new  code  required  full-up  mission  execution.  Mission  execution 
normally  requires  in-water  operations,  since  the  lab  environment  does  not  provide  proper 
inputs  to  ARIES’  navigation  sensors  to  simulate  expected  progress  through  a  operational 
scenario.  In  the  lab  environment  baseline  ARIES  software  generates  multiple  mission 
abort  signals  because  in-lab  sensor  readings  detect  events  such  as  failure  to  reach  way 
points,  exceeding  minimum  allowable  altitude  above  bottom,  or  thruster  failure. 

In-water  testing  also  has  its  limitations.  As  well  as  being  expensive,  labor- 
intensive,  and  dependent  on  weather  conditions,  it  is  also  less  efficient.  It  is  not  possible 
to  remain  logged  on  to  ARIES’  QNXE  and  QNXT  processors  during  an  in-water  run 
since  no  network  connection  is  available  with  ARIES  underway  on  a  mission.  The  result 
is  that  it  is  significantly  more  difficult  and  time-consuming  to  monitor  mission  execution, 
diagnose  improper  execution,  reboot  processors  when  necessary,  and  modify  and 
recompile  code  during  in-water  ARIES  operations. 

To  overcome  these  difficulties  and  accelerate  implementation  of  rendezvous 
operations,  an  in-lab  testing  mode  was  included  in  the  code  for  the  RExec  process.  By 
doing  so,  the  following  ARIES  protective  actions  could  be  temporarily  disabled  for  in-lab 
testing,  then  restored  for  in-water  operations: 

Minimum  altitude  abort:  If  ARIES  altitude  above  bottom  falls  below  a  set 
minimum,  it  suspends  execution  of  its  mission,  turns  to  a  pre-determined 

course  towards  deeper  water,  runs  at  high  speed  for  a  set  period,  and  aborts  its 
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mission.  In  the  lab  sensed  altitude  equals  zero  since  ARIES  acoustic  doppler 
current  profiler  is  in  air,  triggering  this  abort. 

Way  point  time  out  abort:  If  ARIES  position  does  not  satisfy  watch  radius 
criteria  before  expiration  of  the  associated  way  point  time  out;  a  navigation, 
propulsion,  or  control  failure  is  assumed.  Abort  criteria  is  met  and  ARIES 
tenninates  its  mission. 

Additionally,  in-lab  operation  of  thrusters  generally  involves  running  them  in  air, 
which  risks  damaging  them  due  to  lack  of  cooling  and  lubrication. 

The  following  features  were  implemented  in  RExec  to  overcome  these 
impediments: 

A  variable  called  “LAB”  was  defined,  which  is  set  to  “1”  for  in-lab  testing 
and  “0”  otherwise.  The  minimum  altitude  abort  function  is  enabled  only 
when  LAB=0. 

Simulated  navigation  data  is  programmed  into  RExec  code  which  overwrites 
the  navigation  data  received  from  the  nav  process  running  on  QNXT.  Data 
such  as  (X,Y)  position  is  provided  as  a  function  of  time  to  simulate  ARIES 
progressing  through  a  sequence  of  way  points.  This  not  only  allows  execution 
of  a  simulated  in-water  mission,  it  prevents  activation  of  the  way  point 
timeout  abort.  Additionally,  other  parameters  can  be  simulated  to  verity  other 
features  of  ARIES  software.  In  particular,  the  number  of  GPS  satellites 
received  was  simulated  as  a  function  of  time  to  verify  that  expected 
rendezvous  mission  replanning  occurred  following  GPS  fixes. 

Thruster  speed  command  was  made  to  be  contingent  on  the  value  of  LAB. 
When  equal  to  1,  thruster  speed  command  was  reduced  by  a  factor  of  10  to 
pennit  in-air  operation. 

In-lab  testing  consisted  of  approximately  200  missions  to  debug  ARIES 
rendezvous  software.  As  a  result,  with  the  exception  of  compass  error  and  a  minor 
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conflict  between  two  methods  of  periodic  mission  replanning,  ARIES  demonstrated 
expected  rendezvous  behavior  upon  its  first  attempt  in-water. 


97 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


98 


VI.  DEMONSTRATION  OF  CONCEPT 


A.  METHODS 

Demonstration  of  ARIES’  capability  to  perfonn  the  server  vehicle  function  was 
accomplished  via  two  methods. 

Using  the  capability  to  run  missions  in  the  laboratory  environment  developed  for 
this  work,  rendezvous  missions  were  run  in  the  laboratory  with  simulated  navigation  data 
provided  to  the  vehicle.  Navigation  data  consisted  of  a  pre-programmed  sequence  of 
vehicle  positions,  as  well  as  course,  speed,  and  number  of  GPS  satellites.  These 
simulated  parameters  provided  sufficient  input  to  ARIES  rendezvous  software  to  evaluate 
its  perfonnance.  All  vehicle  systems,  including  thrusters,  control  surfaces,  and  sensors 
operated  normally  during  lab  testing.  Actual  acoustic  communications  were  used  for 
sending  commands  to  ARIES  and  for  ARIES  to  transmit  when  required. 

Actual  in- water  missions  were  used  to  further  demonstrate  ARIES’  capabilities. 
Because  a  second  AUV  with  compatible  acoustic  communications  capabilities  was  not 
available,  demonstration  of  the  rendezvous  concept  involved  ARIES  rendezvousing  with 
a  virtual  target  vehicle.  This  target  consisted  of  a  moving  point  in  space  whose  position, 
course,  and  speed  are  programmed  prior  to  the  run  and  could  be  determined  in  post-run 
analysis.  While  target  movements  were  simulated,  actual  target  communications  other 
than  high  bandwidth  data  transfer  communications  were  provided  by  a  Benthos  acoustic 
modem  controlled  by  a  human  operator  on  a  nearby  support  vessel.  It  injected  all 
communications  that  would  have  been  transmitted  by  the  target  vehicle,  providing 
simulated  target  vehicle  communications  for  ARIES  to  process  and  respond  to.  Such 
communications  included  actual  rendezvous  requests  as  well  as  short  messages  signaling 
the  start  and  completion  of  simulated  high  bandwidth  data  transfer  communications. 
Additional  utility  messages  commanded  ARIES  to  report  its  position  or  to  abort  its 
mission. 

Geometry  of  the  operational  area  is  shown  in  Fig.  36.  For  in-water  operations, 
ARIES  started  in  a  100  meter  square  loiter  pattern,  periodically  obtaining  GPS  fixes  to 
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maintain  navigational  accuracy.  For  laboratory  operations  it  was  not  necessary  for  ARIES 
to  maintain  headway  while  awaiting  a  rendezvous  request,  so  the  initial  position  was  a 
single  point. 

In  all  demonstrations  the  target  vehicle  was  assumed  to  follow  a  typical  survey 
pattern  of  advancing  parallel  tracks. 
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Figure  36.  ARIES  Demonstration  Setup 

B.  STATE  MACHINE  AND  RENDEZVOUS  QUEUE,  LABORATORY  RUN 

Proper  operation  of  the  state  machine  and  rendezvous  queue  was  tested  early  in 
the  development  process,  first  as  MATLAB  code,  then  as  stand-alone  C  code  on  ARIES, 
and  finally  as  C  code  integrated  with  all  rendezvous  software.  All  combinations  of  states 
and  input  events  were  applied  to  ARIES  to  verify  that  proper  action  was  taken  when 
expected,  no  action  was  taken  when  no  action  was  expected,  and  that  repeated 
occurrences  of  the  same  event  did  not  cause  ARIES  to  take  repeated  actions.  Tables  3 
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through  6  list  a  sequence  of  events  run  in  the  laboratory  and  ARIES’  correct  response  to 
each.  ARIES’  initial  state  was  LOITER,  with  the  loiter  mission  plan  active. 


Event 

ARIES  Response 

1 .  Invalid  rendezvous  request 

None. 

2.  Valid  rendezvous  request 

Written  to  queue.  State  change  to  PLAN  MSN. 

3.  Plan  is  complete,  infeasible 

State  change  to  LOITER,  request  cleared  from  queue. 

4.  Valid  rendezvous  request 

Written  to  queue.  State  change  to  PLAN  MSN. 

5.  Plan  is  complete,  feasible 

State  change  to  CLOSING.  Rendezvous  plan 

activated 

Table  3.  ARIES  Laboratory  Mission  1,  Events  1-5. 


Event  1  is  a  receipt  of  a  rendezvous  request  that  did  not  meet  the  parsing  criteria 
of  the  RExec  process.  Here  that  the  check  sum  was  incorrect  for  the  remaining  data 
contained  in  the  request.  As  a  result,  the  request  was  disregarded  and  ARIES’  operation 
was  unchanged. 

Event  2  modified  event  1  in  that  the  check  sum  criteria  was  met.  In  response,  the 
request  was  written  to  the  rendezvous  queue  by  the  queue  management  function 
WriteQueue.  This  caused  a  state  transition  to  PLAN  MSN,  and  processing  of  the  request 
by  the  planning  process  RPlan.  Here,  the  resulting  plan  did  not  pass  the  RPlan  feasibility 
check  (event  3).  RPlan  signaled  RExec  that  the  planning  process  was  complete,  but  that 
the  plan  was  infeasible.  As  a  result,  RExec  called  the  ClearQueue  queue  management 
function  to  remove  the  request  from  the  queue,  and  the  state  changed  back  to  LOITER. 

Event  4  modified  event  2  in  that  the  resulting  plan  was  feasible  (event  5).  In 
response,  the  state  machine  set  the  state  to  CLOSING  and  activated  the  rendezvous 
mission  plan  just  created  by  RPlan. 
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Event  6  was  receipt  of  a  signal  that  rendezvous  communications  had  commenced. 
This  was  inserted  to  verify  that  no  response  to  this  event  whould  take  place  in  the 
CLOSING  state. 


Event 

ARIES  Response 

6.  Rendezvous  comins  start 

None. 

7.  Replanning  timer  expires 

State  change  to  PLAN  MSN. 

8.  Plan  is  complete,  feasible 

State  change  to  CLOSING. 

9.  Arrival  at  rendezvous  point 

State  change  to  INIT  RDVZ.  Attempt  comms. 

10.  No  coimns  received  from 

State  changed  to  QUERY  POSIT.  Queries  target  for 

target 

present  position. 

1 1 .  No  target  position  received 

State  change  to  LOITER,  loiter  mission  plan 

activated,  rendezvous  request  cleared  from  queue. 

Table  4.  ARIES  Laboratory  Mission  1,  Events  6-11. 


Event  7  was  the  expiration  of  the  replanning  timer,  which  occurs  when  a  GPS  fix 
is  scheduled  during  the  CLOSING  state  but  no  satisfactory  fix  is  obtained.  This  caused  a 
state  transition  to  the  PLAN  MSN  state,  and  subsequent  reentry  to  the  CLOSING  state 
and  activation  of  the  new  mission  upon  successful  replanning  of  the  rendezvous  mission 
(event  8). 

Event  9  was  arrival  at  rendezvous,  which  caused  transition  to  the  INIT  RDVZ 
state.  In  this  case  ARIES  attempted  to  start  rendezvous  communications,  but  rendezvous 
communications  were  not  received  from  the  target  vehicle  (event  10).  This  triggered 
transition  to  the  QUERY  POSIT  state,  wherein  ARIES  signaled  the  target  vehicle  to 
send  an  updated  rendezvous  request.  In  this  case,  ARIES  received  no  reply  to  its  query 
(event  11),  causing  transition  to  the  LOITER  state.  Along  with  the  state  transition,  the 
loiter  mission  plan  was  activated,  and  the  rendezvous  request  was  cleared  from  the  queue. 
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Event  12  was  another  valid  rendezvous  request;  which  resulted  in  successful 
mission  planning,  transition  to  the  CLOSING  state,  and  activation  of  the  rendezvous 
mission  written  in  response  to  this  request  (event  13).  This  was  followed  by  event  14, 
which  was  a  valid  rendezvous  request  from  a  different  target  vehicle.  Because  ARIES 
was  currently  enroute  to  rendezvous  with  the  first  target  vehicle,  this  request  from  a 


second  vehicle  was  written  to  the 

queue  for  later  processing. 

Event 

ARIES  Response 

12.  Valid  rendezvous  request 

Written  to  queue.  State  change  to  PLAN  MSN. 

13.  Plan  is  complete,  feasible 

State  change  to  CLOSING.  Rendezvous  plan 

activated 

14.  Valid  rendezvous  request 

from  different  target 

Written  to  queue  under  current  request. 

15.  Rendezvous  comins 

complete  signal 

None. 

16.  Arrival  at  rendezvous  point 

State  change  to  INIT  RDVZ.  Attempt  comms. 

17.  No  comms  received  from 

target 

State  changed  to  QUERY  POSIT.  Queries  target  for 

present  position. 

18.  Updated  target  position 

received 

State  changed  to  PLAN  MSN 

19.  Plan  is  complete,  feasible 

State  change  to  CLOSING.  Updated  rendezvous 

plan  activated. 

Table  5.  ARIES  Laboratory  Mission  1,  Events  12-19. 


Event  15  was  similar  to  event  6,  an  event  that  should  elicit  no  response  from 
ARIES  because  ARIES  was  not  in  the  state  for  which  action  should  be  taken.  Because 
the  state  was  CLOSING,  vice  RDVZ,  no  action  was  taken. 
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Events  16  and  17  were  the  same  as  events  9  and  10,  except  in  this  case  the  target 
vehicle  replied  with  a  new  rendezvous  request  reporting  its  present  status  (event  18). 
This  caused  another  transition  to  PLAN  MSN,  and  upon  event  19  ARIES  transitioned 
back  to  the  CLOSING  state  and  activated  the  updated  rendezvous  mission. 


Event 

ARIES  Response 

20.  Arrival  at  rendezvous  point 

State  change  to  INIT  RDVZ.  Attempt  comms. 

21.  Rendezvous  comms  start 

State  change  to  RDVZ 

22.  Rendezvous  comms 

complete 

Current  request  cleared  from  queue.  Next  request 

promoted  to  top  of  queue.  State  changed  to  LOITER, 

then  to  PLAN  MSN  when  request  noted  in  queue. 

23.  Plan  is  complete,  feasible 

State  changed  to  CLOSING.  Rendezvous  plan  for 

second  target  activated. 

24.  Mission  timer  expires 

State  changed  to  TERMINATE.  Terminate  plan 

activated 

Table  6.  ARIES  Laboratory  Mission  1,  Events  20-24. 


Event  20  was  arrival  for  rendezvous,  which  in  this  case  was  immediately  followed 
by  rendezvous  communications  (event  21).  Communications  complete  was  signaled  by 
event  22,  which  caused  transition  to  the  LOITER  state,  clearing  of  the  rendezvous  request 
from  the  queue,  promotion  of  the  subsequent  rendezvous  request  to  the  top  of  the  queue, 
and  activation  of  the  loiter  mission.  However  in  this  case  the  transition  was  only 
momentary,  as  the  state  machine  detected  the  presence  of  a  rendezvous  request  during  its 
next  cycle,  and  ARIES  planned  and  executed  the  rendezvous  for  this  target  vehicle  (event 
23). 

Event  24  was  the  expiration  of  the  overall  mission  timer,  which  immediately 
activated  the  terminate  mission  and  causes  ARIES  to  transit  to  its  recovery  site. 

C.  TIME-OPTIMAL  RENDEZVOUS,  LABORATORY  RUN 
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Having  demonstrated  the  proper  functioning  of  ARIES’  state  machine  and  queue 
management  software,  laboratory  runs  were  conducted  to  verify  proper  functioning  of  the 
planning  process  RPlan  and  of  ARIES  in  general.  The  initial  configuration  of  both 
vehicles  is  shown  in  Fig.  37.  ARIES  was  in  the  LOITER  state,  on  course  000  true,  speed 
0  meters  per  second,  and  the  rendezvous  queue  was  empty.  The  target  vehicle  was  on  its 
fifth  mission  leg,  between  way  points  4  and  5,  on  a  westerly  course,  with  a  speed  of  1.0 
meters  per  second. 
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Figure  37.  Mission  Planning,  Time-Optimal  Rendezvous,  Laboratory  Run 

At  time  =  34.25  seconds  ARIES  received  the  following  message  via  acoustic 
modem: 

RVS,REQ,0,5, 120,30, 155 

which  was  parsed  by  the  modem  process  Rfm  as  shown  in  Table  7. 


1  I  1  1 

Rendezvous  Point 
(900,500.9) 

5 
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This  constitutes  a  valid  message,  and  was  written  to  the  rendezvous  queue.  With 
ARIES  in  the  LOITER  state  and  a  rendezvous  request  in  the  queue  with  a  positive  check 
sum,  the  state  machine  triggered  the  planning  process  RPlan  to  build  a  time-optimal 
rendezvous  plan.  The  time-optimal  mission  planning  process  proceeded  as  discussed  in 
Ch.  V.  RPlan  retrieved  the  target  vehicle  mission  from  memory,  and  applied  the  4.25 
second  transmission  time  delay  from  generation  to  receipt 


Message  Element 

Translation 

RVS,REQ 

Rendezvous  request 

0 

Target  vehicle  number  0  is  the  sender  of  the  request 

5 

Target  vehicle  is  enroute  to  its  waypoint  number  5 

120 

The  target  vehicle  is  120/1000  (12.0%)  down  the  track  from  its 

waypoint  number  4  to  its  waypoint  number  5 

30 

The  data  contained  in  the  rendezvous  request  are  target  vehicle 

parameters  at  time  =  30  seconds.  It  is  4.25  seconds  old 

155 

Check  sum.  Since  this  has  a  positive  value,  a  time-optimal 

rendezvous  is  requested. 

Table  7.  Parsing  of  Laboratory  Time-Optimal  Rendezvous  Request 

of  rendezvous  request  to  the  times  that  it  calculated  for  target  vehicle  arrival  at  its 
previous  and  subsequent  way  points.  The  planning  process  identified  the  first  way  point 
at  which  ARIES  could  feasibly  rendezvous  with  the  target  vehicle.  In  this  case,  it  was  the 
present  waypoint,  waypoint  5.  Using  the  iterative  method  of  finding  the  time-optimal 
rendezvous  point  between  this  way  point  and  the  previous  way  point,  the  planning 
process  identified  points  1,  2,  and  3.  Point  3  is  the  rendezvous  point  and  the  point  at  the 
end  of  the  second  course/speed  change.  Point  2  is  the  start  of  this  course  /  speed  change, 
and  point  1  is  the  end  of  the  first  course  /  speed  change.  Because  the  first  course  /  speed 
change  involved  a  minor  4.33  degree  course  change  but  a  significant  1.5  meter  per 
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second  speed  change,  its  duration  was  determined  by  the  13.5  seconds  required  for 
ARIES  to  accelerate.  Once  on  steady  course  and  speed,  ARIES  trajectory  between  point 
1  and  2  was  a  straight  line  178.7  meters  long  which,  at  1.5  meters  per  second,  could  be 
transited  in  119.1  seconds.  The  final  course  /  speed  change  was  a  significant  94.33 
degree  course  change  and  minor  0.5  meter  per  second  speed  change,  so  its  duration  was 
determined  by  the  26.0  seconds  required  to  complete  the  turn.  As  a  result,  the  plan 
brought  ARIES  to  point  3,  the  rendezvous  point,  158.6  seconds  into  the  future,  at  which 
time  it  should  match  target  vehicle  course  and  speed.  Its  position  along  the  track  at  that 
time  was  projected  to  be  Y=500.9,  which  was  0.3  meters  ahead  of  the  target  vehicle’s 
projected  Y=501.2  position.  With  velocities  and  positions  matched,  the  vehicles  meet  the 
definition  of  rendezvous. 

Using  these  points,  the  planning  process  created  the  rendezvous  mission  described 
by  the  way  point  file  shown  in  Table  8,  which  is  in  the  ARIES  format  of  the  previous 
chapter.  The  first  two  way  points  are  points  2  and  3.  Note  that  the  distance  to  the  first 
waypoint  is  greater  than  100  meters,  so  that  a  “1”  appears  in  the  eighth  column  to  obtain 
a  GPS  fix  during  this  leg  to  update  ARIES’  position.  The  final  three  waypoints  are  the 
next  three  target  waypoints,  waypoints  5,  6,  and  7. 
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Table  8.  ARIES  Initial  Rendezvous  Mission,  Laboratory  Time  Optimal  Run. 

ARIES  activated  this  rendezvous  mission,  and  at  time  =  75  seconds  its  simulated 
position  was  greater  than  30%  of  the  way  down  the  first  leg  of  its  rendezvous  mission, 
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which  contains  a  GPS  pop-up.  Having  met  GPS  pop-up  criteria  it  surfaced,  and  at  that 
point  began  to  sense  the  simulated  reception  of  three  GPS  satellites.  In  accordance  with 
the  GPS  reception  logic  written  into  the  RExec  process,  after  ten  seconds  of  this  GPS 
reception  rendezvous  mission  replanning  occurred.  The  situation  is  shown  in  Fig  38. 
Because  ARIES’  GPS  position  was  different  from  its  position  had  precisely  followed  the 
course  and  speed  of  its  rendezvous  trajectory,  it  was  necessary  to  replan  the  rendezvous 
based  on  updated  vehicle  positions.  This  is  done  as  it  was  done  above,  and  the  result  was 
a  new  time-optimal  rendezvous  point.  Note  that  ARIES  position  was  further  from  the 
rendezvous  point  than  was  expected,  which  lengthened  the  time  remaining  until  the 
earliest  possible  rendezvous.  As  a  result,  the  updated  rendezvous  is  later,  10.6  meters 
further  down  the  target’s  track. 
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Figure  38.  Mission  Replanning,  Time-Optimal  Rendezvous,  Laboratory  Run. 
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Following  replanning  of  the  rendezvous  mission,  ARIES  continued  on  to  the 
rendezvous  point.  The  next  several  events  and  ARIES  responses  were  nominal,  as 
presented  in  the  previous  section  and  shown  in  Table  9. 


Time 

Event 

ARIES  Response 

(Sec) 

180 

Arrival  at  rendezvous  point 

State  change  to  INIT  RDVZ.  Attempt  comms. 

189 

Rendezvous  coimns  start 

State  change  to  RDVZ 

200 

Rendezvous  coimns 

complete 

Current  rendezvous  request  cleared  from  queue. 

State  changed  to  LOITER,  loiter  mission  activated. 

Table  9.  Events  and  Responses  Following  Mission  Replanning,  Time-Optimal  Laboratory 

Run. 

The  final  event  of  this  run  was  a  GPS  popup  while  ARIES  was  enroute  to  the 
loiter  pattern.  Since  mission  replanning  applies  only  to  the  rendezvous  mission  and  can 
only  occur  while  ARIES  is  in  the  CLOSING  state,  the  loiter  mission  is  unaffected. 
Although  the  mission  waypoint  file  remains  unchanged,  the  fix  provides  data  that  updates 
ARIES’  position  and  improves  its  navigation  accuracy. 

D.  ENERGY-OPTIMAL  RENDEZVOUS,  LABORATORY  RUN 

The  initial  conditions  for  this  run  were  identical  to  the  time-optimal  run.  At  time 
=  34  seconds  ARIES  received  the  following  message  via  acoustic  modem: 

RVS,REQ, 0,5, 120,30,-155 

This  is  identical  to  the  rendezvous  request  from  the  time  optimal  run,  except  the  check 
sum’s  negative  sign  signals  that  the  rendezvous  will  be  planned  as  energy  optimal.  As 
discussed  in  Ch.  V,  the  initial  portion  of  the  energy-optimal  planning  process  is  to 
determine  the  time-optimal  rendezvous  point,  which  establishes  the  earliest  bound  on  the 
time  period  during  which  an  energy  optimal  rendezvous  may  occur.  Because  the  target 
vehicle  position  data  contained  in  this  rendezvous  request  is  identical  to  the  time-optimal 
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case,  and  the  time  delay  for  receiving  this  request  was  only  0.25  seconds  different  from 
the  time-optimal  case,  the  earliest  possible  energy-optimal  rendezvous  point  was 
essentially  the  original  time-optimal  rendezvous  point  bound  from  the  previous  case. 
Therefore  the  earliest  possible  rendezvous  occurred  on  target  mission  leg  5. 

As  discussed  in  Ch.  V,  the  latest  possible  energy-optimal  rendezvous  is  found  as 
the  time  optimal  rendezvous  for  ARIES’  lowest  speed,  1.0  meters  per  second.  Sampling 
the  target  track  every  20  meters  between  these  two  bounds  and  detennining  the  energy 
required  for  rendezvous  at  each  point  yielded  the  point  (900,420)  as  the  energy  optimal 
rendezvous  point,  as  shown  in  Fig.  39. 
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Figure  39.  Energy  to  Rendezvous  versus  Rendezvous  Position,  Energy-Optimal  Laboratory 

Run 

After  locating  the  energy-optimal  rendezvous  point,  the  planning  process  built  the 
rendezvous  mission  waypoint  file  to  get  ARIES  to  the  rendezvous  point.  This  planning 
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process  is  similar  to  that  used  in  the  time-optimal  case,  except  instead  of  adjusting  the 
rendezvous  point  location  with  closure  speed  fixed,  closure  speed  is  adjusted  while 
holding  the  rendezvous  point  fixed.  The  process  is  illustrated  in  Fig.  40. 
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Figure  40.  Mission  Planning,  Energy-Optimal  Rendezvous,  Laboratory  Run 

After  ARIES  activated  the  rendezvous  mission,  the  rendezvous  proceeded  as  in 
the  time-optimal  case,  with  the  mission  replanned  once  in  response  to  a  GPS  fix. 

E.  TIME-OPTIMAL  RENDEZVOUS,  IN- WATER  RUN 

The  initial  in-water  time  optimal  run  is  depicted  in  Fig.  41.  ARIES  began  the  run 
in  the  loiter  state,  traversing  its  loiter  pattern  in  a  clockwise  direction  and  fixing  its 
position  with  GPS  periodically.  At  time  =  662.125  seconds,  ARIES  received  the 
following  rendezvous  request  from  target  number  2: 

2,2,96,660,760 
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This  request  parses  to  a  time-optimal  request  from  target  #2,  located  9.60%  of  the  way 
between  its  waypoints  1  and  2  at  time  660  seconds.  As  before  the  planning  process 
identified  the  time-optimal  rendezvous  point,  which  in  this  case  was  located  on  the  third 
leg  of  the  target’s  mission.  The  mission  was  feasible  and  ARIES  departed  its  loiter 
pattern  to  begin  closing  the  rendezvous  point. 


Figure  4 1 .  Time-Optimal  Rendezvous,  In- Water  Run 

At  time  =  782.375  seconds  ARIES  replanned  the  rendezvous  mission.  During 
closure  ARIES  actual  speed  through  the  water  had  been  1.6  meters  per  second,  not  1.5 
meters  per  second  as  planned  by  the  planning  process.  This  was  due  to  ARIES’  open- 
loop  speed  control.  Ballasting  and  hydrodynamic  variations  resulted  in  a  higher  than 
expected  speed.  Mission  replanning  took  this  speed  difference  into  account,  adjusting  the 
rendezvous  point  for  ARIES  actual  position  which  was  further  down  track  than  expected; 
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and  using  the  better-than  expected  progress  towards  the  rendezvous  point  to  plan  a  new, 
earlier  rendezvous.  The  result  was  a  four  degree  course  adjustment  to  the  left,  towards 
the  earlier  rendezvous  point. 

At  time  t  =  909  seconds  ARIES  arrived  at  the  rendezvous  point  X=950,  Y=617.3. 
Projecting  the  target  vehicle’s  rendezvous  request  position  forward  to  this  time,  its 
position  would  be  X=950,  Y=903.8.  Therefore  ARIES  arrived  approximately  5.2  meters 
ahead  of  expected  position  of  the  target  vehicle.  This  miss  distance  is  within  range  of  all 
present  high-speed  underwater  communications  systems,  and  was  primarily  due  to  the 
speed  error  during  closure.  ARIES’  accumulated  position  error  due  to  the  0.1  meter  per 
second  speed  error  during  the  127  seconds  of  closure  since  mission  replanning  would 
have  been  approximately  13  meters. 

ARIES  controls  and  state  responses  are  shown  in  Fig.  42.  As  discussed  in  Ch.  Ill, 
rudder  control  is  “bang-singular-bang”  while  enroute  to  rendezvous,  with  approximately 
zero  rudder  during  the  singular  arc.  Speed  control  is  “bang-bang”. 
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Figure  42.  ARIES  Speed  Command  and  Speed,  Rudder  Angle,  and  Heading,  Time-Optimal 

Rendezvous,  In- Water  Run 
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ARIES  rendezvoused  with  the  target  for  120  seconds.  At  the  rendezvous  point 
ARIES  unsuccessfully  attempted  to  establish  rendezvous  communications,  which  were 
provided  by  a  modem-equipped  support  vessel.  As  a  result,  ARIES  queried  for  target 
vehicle  position  at  time  =  976.625  seconds.  When  no  reply  was  received  by  time  =1036 
seconds  ARIES  abandoned  the  rendezvous  attempt,  as  directed  by  the  state  machine,  and 
returned  to  its  loiter  area. 

F.  ENERGY-OPTIMAL  RENDEZVOUS,  IN- WATER  RUN 

The  initial  in-water  energy-optimal  run  is  depicted  in  Fig.  43. 


Figure  43.  Closure  for  Energy  Optimal  Rendezvous,  In- Water  Run 

ARIES  again  started  in  its  loiter  pattern.  At  time  =  242  seconds  it  received  the 
rendezvous  request 

RVS,REQ,0,7,500,240,-747 

which  signaled  that  the  target  number  0  was  50%  of  the  way  down  its  seventh  leg  at  time 
240  seconds,  and  that  the  rendezvous  will  be  energy  optimal.  The  planning  process 
identified  three  candidate  rendezvous  points  at  which  rendezvous  fell  within  ARIES 
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speed  range.  The  leftmost  point  required  the  least  energy,  and  rendezvous  was  planned 
for  that  point.  Replanning  occurred  at  two  later  times  based  on  reception  of  satisfactory 
GPS  fixes  scheduled  to  occur  at  those  points.  The  first  replanning  resulted  in  selection  of 
the  same  rendezvous  point  as  initial  planning.  Due  to  variations  in  actual  ARIES  speed 
and  external  disturbances  during  closure,  the  second  replanning  process  selected  the 
center  candidate  rendezvous  point.  Shortly  after  this  final  replanning  of  the  rendezvous, 
ARIES  aborted  its  mission  due  to  inadequate  battery  power  for  propulsion.  Projection  of 
ARIES’  and  the  target’s  future  movements  indicated  that  the  vehicles  would  have 
rendezvoused  within  approximately  30  meters. 
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VII.  CONCLUSION 


A.  SUMMARY 

This  work  develops  a  high-bandwidth  concept  for  accelerating  access  to 
information  gathered  by  AUVs.  This  cooperative  behavior  enhances  AUV  operations 
and  increases  their  value  and  effectiveness  in  networked  naval  operations  as  envisioned 
in  the  UNO’s  “Sea  Power  21”  guidance  for  future  Naval  operations. 

The  data  transfer  method  utilizes  rendezvous  between  AUVs  to  enable  the  use  of 
high  bandwidth  optical  or  acoustic  communications  links  between  vehicles.  A  server 
vehicle,  whose  role  is  to  transfer  survey  data  from  sensor  vehicles  to  a  larger  network, 
comes  into  close  proximity  with  a  sensor  vehicle  to  receive  the  data.  This  is  necessary 
because  high  bandwidth  underwater  communications  methods  are  of  limited  range,  This 
concept  also  provides  a  greater  degree  of  covertness  than  radio  links  with  the  sensor 
vehicle. 

Because  of  limitations  on  AUV  energy  resources,  and  because  access  to  such  data 
may  be  time-sensitive,  efficiency  is  a  goal  of  the  rendezvous  process.  Since  most 
literature  on  rendezvous  deals  with  spacecraft  operations,  intercept  methods  were 
investigated  for  application  to  AUV  rendezvous.  Intercept  is  similar  to  rendezvous  in 
that  the  goal  is  to  match  the  future  position  of  a  target  vehicle.  Rendezvous  imposes  the 
additional  constraint  that  target  vehicle  be  matched  as  well.  Doing  so  brings  both 
vehicles  in  close  proximity  with  no  relative  motion  such  that  communications  can  be 
exchanged.  The  relative  merits  of  intercept  methods  are  dependent  on  the  geometry  of 
the  particular  problem,  owing  to  the  lack  of  information  on  target  maneuvers  during  the 
intercept.  This  work  demonstrates  how  such  information,  which  should  be  available 
between  cooperating  vehicles,  enhances  the  efficiency  of  the  rendezvous  process. 

Efficiency  was  then  defined  as  time-optimal  or  energy-optimal  rendezvous, 

depending  on  whether  the  objective  is  the  most  rapid  access  to  data  or  conservation  of 

vehicle  energy  reserves.  Using  principles  of  optimal  control,  the  characteristics  of  the 

optimal  rendezvous  trajectories  were  determined  for  both  cases.  For  time  optimal 

rendezvous  the  solution  was  found  to  be  bang-singular-bang  rudder  control  and  bang- 

117 


bang  speed  control.  The  chaser  vehicle  immediately  accelerates  to  and  maintains 
maximum  speed  until  such  time  that  stopping  propulsion  causes  the  vehicle  to  decelerate 
to  target  vehicle  speed  at  the  rendezvous  point.  It  also  executes  two  course  changes, 
using  maximum  rudder  until  on  a  heading  to  close  the  target  vehicle  and  remaining  on 
this  heading  until  a  final  maximum  rudder  turn  that  brings  it  to  the  position  and  heading 
of  the  target  vehicle  at  the  same  speed.  The  rendezvous  point  is  uniquely  defined  as  the 
earliest  for  which  the  target  vehicle’s  state  fall  into  the  set  of  chaser  vehicle  reachable 
states.  In  order  to  detennine  the  energy-optimal  rendezvous  trajectory,  the  vehicle’s 
power  requirement  as  a  function  of  speed  must  be  known.  Installation  of  a  current  sensor 
in  the  NPS  ARIES  vehicle  made  this  possible  for  the  ARIES  vehicle,  and  data  showed 
that  the  vehicle’s  power  characteristics  are  a  typical  combination  of  a  constant  hotel  load 
and  a  cubic  propulsion  load.  The  energy-optimal  rendezvous  solution  involves  bang- 
singular-bang  control  of  both  speed  and  rudder.  Rudder  control  is  similar  to  the  time- 
optimal  case,  while  speed  control  involves  a  final  speed  change  to  match  target  speed  and 
an  initial  speed  change  to  a  most-efficient  speed  to  close  the  target.  This  speed  is 
dependent  on  problem  geometry,  and  may  not  be  attainable  due  to  lower  limits  on  vehicle 
speed  imposed  by  vehicle  buoyancy  and  control  considerations.  The  minimum  energy 
solution  is  not  unique,  but  operational  considerations  would  probably  drive  towards 
selecting  the  earliest  of  multiple  solutions. 

These  solutions  were  then  implemented  by  upgrading  the  operational  software  of 
the  ARIES  vehicle  to  allow  it  to  perform  the  server  vehicle  function.  Whereas  ARIES  is 
a  typical  AUV  utilizing  autopilots  for  vehicle  control  and  mission  scripts  and  way  point 
files  to  define  a  mission,  rendezvous  requires  a  higher  level  operational  control.  In  order 
to  rendezvous,  ARIES  must  communicate  effectively  with  the  other  vehicle,  must  plan  its 
mission  based  on  infonnation  received  from  the  other  vehicle,  must  activate  the  mission 
and  follow  it  to  the  rendezvous  point,  must  periodically  replan  the  rendezvous  mission  to 
account  for  navigational  changes  enroute,  must  provide  a  level  of  robustness  to  deal  with 
navigational  and  communications  failures,  and  must  properly  sequence  this  complex 
collection  of  activities. 
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ARIES  communications  software  was  upgraded  to  allow  exchange  of  rendezvous 
information  and  to  allow  ARIES  to  initiate  communications. 

A  mission  planning  module  was  written  to  process  incoming  requests  to 
rendezvous,  combine  the  infonnation  contained  in  the  request  with  pre-stored  target 
vehicle  mission  parameters,  and  generate  a  rendezvous  mission  waypoint  file  to  bring 
ARIES  efficiently  to  the  rendezvous  point  in  either  a  time-optimal  or  energy-optimal 
manner. 

ARIES  mission  activation  software  was  rewritten  to  allow  activation  of  way  point 
files  whenever  appropriate,  rather  than  only  at  the  start  of  a  mission  as  is  typically  the 
case  with  AUV  missions.  Additionally  a  rendezvous  queue,  along  with  queue 
management  routines,  was  added  to  coordinate  the  processing  of  requests  from  multiple 
target  vehicles. 

To  coordinate  ARIES’  rendezvous  operations  an  additional  layer  of  control  was 
added.  A  finite  state  machine  was  implemented  which  defined  the  rendezvous  mission  as 
a  series  of  seven  states.  The  state  machine  defined  a  series  of  mission  events,  and 
ordered  state  transitions  to  occur  whenever  transition  criteria  were  met. 

ARIES  proper  functioning  as  a  server  vehicle  capable  of  rendezvousing  with 
other  vehicles  was  then  verified.  A  laboratory  operational  mode  was  developed  for 
ARIES,  allowing  ARIES  to  run  simulated  missions  in  the  laboratory  environment.  This 
greatly  reduced  the  amount  of  time  needed  to  debug  the  significant  code  changes 
necessary  to  perform  rendezvous  operations,  and  provided  a  means  to  demonstrate 
ARIES  proper  operation  as  a  rendezvous-capable  server  vehicle.  In-water  runs  with  a 
surrogate  target  vehicle  and  using  a  support  vessel  to  provide  communications  inputs  to 
ARIES  further  demonstrated  ARIES  correct  functioning  as  a  server  vehicle. 

B.  RECOMMENDATIONS 

This  work  developed  and  demonstrated  the  server  vehicle  rendezvous  behavior  on 
the  ARIES  AUV,  however  an  operational  system  would  require  the  following  additional 
developments. 
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A  high  bandwidth  communications  link  should  be  installed  on  the  server  vehicle 
to  provide  the  high-speed  data  transfer  capability  that  is  the  motivation  for  this  work. 

Implementation  of  closed-loop  control  of  server  vehicle  speed  would  improve 
navigation  to  the  rendezvous  point.  This  implementation  used  open-loop  speed  control 
based  on  previous  determination  of  the  relationship  between  steady-state  thruster  and 
vehicle  speeds.  Closing  this  loop,  particularly  for  energy-optimal  rendezvous,  would 
improve  the  server  vehicle’s  ability  to  reach  the  rendezvous  point  at  the  computed  time  of 
rendezvous.  In  the  time-optimal  case,  since  the  objective  is  to  rendezvous  as  soon  as 
possible,  a  logical  and  analogous  improvement  would  be  to  command  maximum  vehicle 
speed  as  was  done  here,  but  to  use  actual  measured  speed  in  the  rendezvous  planning 
process.  This  would  still  provide  minimum-time  transit  to  the  rendezvous  point,  while 
providing  more  accurate  data  to  the  planning  process. 

Because  of  the  limited  range  of  high-bandwidth  underwater  communications 
equipment,  it  would  be  beneficial  for  server  vehicle  navigation  to  shift  to  a  mode  based 
on  sensed  survey  vehicle  position  once  rendezvous  is  achieved.  The  implementation 
presented  here  is  based  on  a  global  frame  of  reference  for  both  vehicles,  wherein  the 
accuracy  with  which  the  server  vehicle  can  close  the  survey  vehicle  is  affected  by  the 
global  position  uncertainty  of  both  vehicles.  At  best,  several  meters  of  error  would  be 
expected  if  using  typical  global  navigation  methods  such  as  GPS  or  long-baseline 
acoustic  navigation.  However  once  the  rendezvous  point  is  reached  using  a  global 
reference  frame,  if  the  server  vehicle  is  able  to  sense  the  position  of  the  survey  vehicle 
directly  and  shift  to  a  navigation  frame  of  reference  centered  on  it,  the  server  vehicle 
should  be  able  to  control  its  position  relative  to  the  survey  vehicle  with  accuracy  superior 
that  of  the  global  reference  frame.  This  may  be  necessary  for  extremely  short  range  or 
highly  directional  communications  systems. 

Compatible  survey  vehicles  must  be  added  to  the  operation  to  create  the  vehicle 

network.  Such  vehicles  should  be  configured  with  both  command-and-control  mode  and 

rendezvous  mode  communications  equipment,  and  this  equipment  must  be  integrated 

with  the  vehicle’s  processors.  Vehicle  logic  must  determine  when  an  event  warranting 

transmission  of  a  rendezvous  request  has  occurred,  determine  vehicle  state,  generate  the 
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request  containing  the  state  information,  and  transmit  it.  Logic  should  also  determine 
when  to  issue  subsequent  rendezvous  requests  if  rendezvous  does  not  occur.  Rendezvous 
mode  communications  equipment  must  be  integrated  with  the  sensors  gathering  survey 
data,  to  transfer  the  data  once  rendezvous  commences. 

Survey  vehicles  should  also  be  dynamically  compatible  with  the  server  vehicle  so 
that  rendezvous  is  possible.  The  survey  vehicle  should  not  operate  at  speeds  greater  than 
the  server  vehicle,  and  turn  dynamics  should  be  compatible  so  that  rendezvous  operations 
are  not  unduly  disrupted  during  turns.  Additionally,  for  directional  communications 
systems,  the  motions  of  both  vehicles  must  be  controlled  to  avoid  disruption  of  the 
communications  link  during  data  transfer. 
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